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为 什么 要 写 这 本 书 


作为 置身 于 IT 技术 领域 多 年 的 实践 者 和 教育 者 ， 我 们 一 直 盼 望 着 
行业 迎 来 这 样 一 个 时 刻 : 异 构 的 IT 基础 设施 环境 所 造成 的 开发 和 部 署 
系统 应 用 纷繁 复杂 的 局 面 终 于 迎 来 了 终结 者 ， 开 发 人 员 无 须 再 考虑 复 
杂 多 样 的 运行 环境 下 软件 程序 的 移植 问题 ， 运 维 人 员 不 用 再 手动 解决 
运行 环境 中 组 件 间 的 依赖 关系 等 ， 从 而 让 各 目的 核心 职责 都 回归 到 开 
发 和 保证 系统 稳定 运行 本 号 。 终 于 ， 以 Docker 为 首 的 容 希 技术 为 此 市 
来 了 基础 保障 ， 并 在 容 需 编排 技术 的 文 撑 下 人 尘埃 落 定 ， 甚 至 连 IT 管理 
者 心心 念 念 多 年 的 DevOps 文 化 运动 也 借 此 找到 了 易于 落地 的 实现 方 
案 。 于 是 ， 系 统 运行 割据 多 年 的 局 面 终 于 将 走 癌 天 下 一 统 。 


尽管 距 Kubernetes 1.0 的 发 布 不 过 三 四 年 的 光景 ， 但 其 如 今 的 影响 
力 在 IT 技术 领域 完全 算得 上 空前 绝 后 ， 目 前 ， 一 众 大 小 公司 都 在 使 用 
或 正 筹划 使 用 这 一 IT 技术 发 展 史 上 可 能 最 为 成 功 的 开源 项 目 。Linux 软 
件 基 金 会 的 常务 董事 Jim Zemlin 在 Google Cloud Next 17 大 会 上 曾 表 
示 ，Kubernetes 是 “ 云 时 代 的 Linux”。 的 确 ，Kubernetes 应 该 是 开源 世界 
有 史 以 来 迭代 最 快 的 项 目 ， 而 旦 在 几乎 所 有 需要 采用 容 佛 技术 的 场景 
里 成 为 占 统 治 地 位 的 解决 方案 ， 其 发 展 速 度 您 怕 也 仪 有 Linux 内 核 项 目 
可 堪 死 和 酸 。2018 年 3 月 ，Kubernetes 成 为 CNCF 旋 下 “毕业 ”的 第 一 个 项 
目 ， 并 荣获 2018 年 OSCON 最 具 影 响 力 奖 项 。 


目前 ，Kubernetes 保 持 着 每 年 发 布 四 个 重要 版 本 的 广 奏 ， 版 本 的 
每 次 更 狐 都 会 引入 数 个 新 特性 。 这 种 快速 从 代 的 机 制 在 为 用 户 不 断 带 
来 惊喜 的 同时 ， 也 给 他 们 在 学 习 和 使 用 上 造成 了 一 些 困扰 : 相关 领域 
的 可 参考 书籍 仍 不 丰 宣 ， 互 联网 上 可 以 得 到 的 众多 文档 并 非 源 于 同一 
个 版 本 ， 以 及 厘清 脉络 拼 竣 成 完整 的 知识 框架 所 需 的 时 间 成 本 较 大 。 
因此 ， 我 在 课程 以 及 直接 或 间接 参与 生产 或 测试 环境 的 交付 之 余 便 戎 
生 了 撰写 一 本 Kubemetes 入 1 门 、 进 阶 与 实战 的 书籍 的 想法 ， 将 目 己 学 
习 和 使 用 的 经 验 总 结 、 沉 尝 并 分 享 给 更 多 有 此 需求 的 技术 同行 ， 帮 助 
0 降低 时 间 成 本 ， 并 迅速 投入 测试 和 生产 之 


的 确 ， 在 写作 过 程 中 ，Kubermnetes 这 种 快速 迭代 的 机 制 ， 以 及 每 
每 引入 的 新 特性 ， 在 小 惊喜 之 余 市 给 笔者 更 多 的 却 是 真 真切 切 的 梦 碑 
般 的 芍 慢 感 : 在 一 年 多 的 写作 时 间 里 ， 许 多 章 广 儿 易 其 稿 ， 却 也 依然 
无 法 确保 能 够 泗 盖 即将 成 为 核心 功能 的 特性 ， 于 是 诅 起 感 儿 度 如 影 随 
形 ， 直 到 目 我 安奈 着 “基础 的 核心 特性 基本 不 会 发 生 大 的 变动 ， 只 要 能 
帮助 读者 弄 清楚 Kubernetes 系 统 的 基础 架构 及 核心 工作 逻辑 就 算 工 夫 
没有 白费 ”之 后 方才 释然 。 于 是 便 有 了 这 本 力图 尽量 多 地 包罗 
Eo 之 圳 工具 之 


本 书 特色 


本 书 致力 于 帮助 容 丹 编排 技术 的 初级 和 中 级 用 户 循序 渐进 地 理解 
与 使 用 Kubernetes 系 统 ， 因 此 本 书 的 编写 充分 考虑 到 初学 者 进入 新 知 
识 领域 时 的 茫然 ， 采 用 由 浅 入 深 、 提 纲 玫 领 、 再 由 点 到 面 的 方式 讲解 
每 一 个 知识 细节 。 对 于 每 个 知识 点 ， 不 仅 介绍 了 其 概念 和 用 法 ， 还 分 
析 了 为 什么 要 有 这 个 概念 ， 实 现 的 方式 是 什么 ， 背 后 的 逻辑 为 何 ， 等 
等 ， 使 读者 不 仪 能 知 其 然 ， 还 能 知 其 所 以 然 。 

本 书 不 仅 要 带领 读者 入 门 ， 更 是 一 本 可 以 随时 动手 加 以 验证 的 实 
践 手册 ， 而 且 对 于 部 分 重要 的 内 容 还 会 专门 一 步 步 地 给 出 具体 的 实 操 
案例 ， 帮 助 读者 在 实践 中 升华 对 概念 的 理解 。 本 书 儿 乎 涵盖 了 应 用 
Kubernetes 系 统 的 所 有 主流 知识 点 ， 它 甚至 可 以 作为 计划 考取 CKA 认 
证 的 读者 的 配套 参考 图 书 。 


读者 对 象 
: 云 计 算 工 程 师 
. 运 维 工程 师 
系统 开发 工程 师 
-程序 架构 师 
:计划 考取 CKA 认 证 的 人 员 


其 他 对 容 絮 编排 感 兴趣 的 人 员 
如 何 阅 读本 书 


阅读 使 用 本 书 之 前 ， 读 者 需要 具备 Docker 容 需 技 术 的 基础 使 用 能 
力 。 本 书 逻 辑 上 共 分 为 五 大 部 分 ，15 章 。 


第 一 部 分 (第 1 一 2 章 ) ， 介 绍 Kubernetes 系 统 的 基础 概念 及 其 基 
第 1 章 介绍 容器 编排 系统 出 现 的 背景 ， 以 及 Kubermetes 系 统 的 功 
能 、 特 性 、 核 心 概念 、 系 统 组 件 及 应 用 模型 。 


第 2 草 讲解 Kubernetes 的 核心 对 象 ， 以 及 直接 使 用 命令 管理 资源 对 
象 的 快速 入 门 技巧 。 
二 部 分 〈 第 3 一 6 章 ) ， 介 绍 核心 资源 类 型 及 其 应 用 。 

第 3 草 介绍 资源 管理 模型 、 陈 述 式 与 声明 式 资 源 管理 接口 ， 并 通 
过 命令 对 比 说 明 两 种 操作 方式 的 不 同 之 处 。 

第 4 章 介绍 Pod 资 源 的 利用 配置 、 生 命 周 期 、 存 储 状 态 和 就 绪 状 态 
全 测 ， 以 及 计算 资源 的 需求 及 限制 等 。 


第 5 章 介绍 Pod 挥 制 妖 资源 类 型 ， 重 点 讲解 了 控制 无 状态 应 用 的 
ReplicaSet、Deployment、DaemonSet 控 制 絮 ， 并 介绍 了 Job 和 CronJob 
控制 器 。 


第 6 草 介绍 Service 和 Ingress 资 源 尖 型 ， 洱 次 Service 类 型 、 功 用 及 
其 实现 ， 以 及 Ingress 控 制 器 \Ingress 资 源 的 种 类 及 其 实现 ， 并 通过 案 
例 详 细 说 明了 Ingress 资 源 的 具体 使 用 方式 。 

第 三 部 分 〈 第 7~-9 章 ) ， 介 绍 存储 卷 及 StatefulSet 控 制 器 。 


第 7 章 主要 介绍 存储 卷 类 型 及 常见 存储 卷 的 使 用 方式 、PV 和 和 PVC 
出 现 的 原因 及 应 用 ， 以 及 存储 类 资源 的 应 用 和 存储 卷 的 动态 供给 。 


小 


第 8 章 介绍 使 用 一 等 资源 类 型 ConfigMap 和 Secret 为 容 右 应 用 提供 
配置 及 敏感 信息 的 方式 。 


第 9 章 主要 介绍 有 状态 应 用 的 Pod 控 制 句 资源 StatefulSet， 包括 基 
础 应 用 、 动 态 扩 缩 容 及 更 新 机 制 等 。 


第 四 部 分 (第 10~~11 章 ) ， 介 绍 安 全 相关 的 话题 ， 主 要 涉及 认 
证 、 授 权 、 准 入 控制 、 网 络 模型 与 网 络 策 略 。 


第 10 草 重点 讲解 认证 方式 、Service Account 和 和 TLS 认证、 授权 插 
件 类 型 及 RBAC， 并 于 章 世 的 最 后 介绍 LimitRanger 、ResourceQuota 和 
PodSecurityPolicy 三 种 类 型 的 准 入 挥 制 絮 及 相 天 的 资源 类 型 。 


第 11 章 主要 介绍 网 络 插件 基础 及 flannel 的 三 种 后 端 实现 与 应 用 、 
E00 0 以 及 Calico 网 络 插件 的 基础 使 


第 五 部 分 〈 第 12~15 章 ) ， 介 绍 Kubernetes 系 统 的 高 级 话题 。 


“第 12 章 介绍 Pod 资 源 的 调度 策略 及 高 级 调度 方式 的 应 用 ， 包 括 节 
点 亲 和 、Pod 资 源 亲 和 以 及 基于 污点 和 容忍 度 的 调度 。 


第 13 章 介绍 系统 资源 的 扩展 方式 ， 包括 日 定义 资源 类 型 、 自 定义 
资源 对 象 、 目 定义 API 及 控制 器 、Master 闻 点 的 高 可 用 、 基 于 
Kubernetes 的 PaaS 系 统 等 话题 。 


第 14 章 介绍 资源 指标 、 目 定义 指标 、 监 控 系 统 及 HPA 控 制 器 的 应 


oO 


第 15 间 介绍 简化 应 用 管理 的 工具 Helm， 并 基于 Helm 介 绍 如 何 为 
Kubernetes 系 统 提 供 统 一 的 日 志 收 集 与 管理 工具 栈 EFK 。 


有 一 定 Kubernetes 使 用 经 验 的 读者 可 以 挑选 感 兴趣 的 章 世 阅读 。 
而 对 于 初学 者 ， 建 议 从 基础 部 分 逐 章 阅读 ， 但 构建 在 Kubernetes 系 统 
之 上 的 应 用 多 数 都 要 求 读者 能 熟练 使 用 相关 领域 的 知识 和 技能 ， 如 果 
对 某 些 内 容 的 理解 比较 困难 ， 那 么 可 能 是 由 于 相关 知识 欠缺 ， 建 议 读 
考 通 过 其 他 资料 补充 学 习 相 关 知 识 后 再 阅读 本 书 。 编 所 本 书 的 主要 意 


图 十 为 初学 者 提供 一 个 循序 渐进 的 实 操 手册 ， 不 过 ， 任 何 读 者 也 都 可 
以 将 它 作 为 一 本 案头 的 工具 书 随时 进行 查阅 。 


排版 约定 


本 书 中 所 有 的 命令 都 附带 了 或 长 格式 或 短 格式 的 命令 提示 符 ， 以 
便 读者 区 分 文中 正常 使 用 的 “#” 和 “$”， 命 令 提 示 格 式 为 “~]#" 或 “~]$”， 
命令 使 用 了 只 为 续 行 符 ， 且 命令 及 其 输出 使 用 了 有 别 于 正文 的 
子 O 


更 多 内 容 和 附带 代码 


本 书 相 关 的 配置 清单 等 都 放置 于 https:/github.coryikubernetes/ 的 
相关 仓库 中 ， 在 实践 中 需要 时 可 直接 克隆 至 本 地 实验 环境 中 使 用 。 


勘误 和 文 持 


尽管 进行 授课 及 技术 写作 已 十 数 年 ， 但 动笔 彰 书 尚 属 首 次 ， 考 虑 
到 排版 印刷 后 的 表述 无 可 更 改 ， 整 个 写作 过 程 战 战 殉 殉 、 如 履 注 冰 。 
进行 每 一 个 关键 话题 的 表述 之 前 都 查阅 了 大 量 资料 ， 并 且 反 复 鞋 酌 ， 
既 期 望 能 够 将 知识 点 清晰 、 准 确 地 加 以 摘 述 ， 也 试图 避免 因 目 己 的 理 
解 偏差 而 误导 读者 。 尽 管 如 此 ， 由 于 笔者 水 平 有 限 ， 加 之 编写 时 间 仓 
促 ， 书 中 难免 存在 不 妥 之 处 ， 且 请 读者 批评 指正 。 如 有 果 读 者 有 更 多 的 
宝贵 意见 ， 请 通过 邮箱 mage@magedu.com 联系 我 ， 期 待 能够 得 到 你 们 
的 真 倪 反馈， 在 技术 之 路 上 互 揭 共 进 。 另 外 ， 本 书 的 勘误 将 会 发 布 在 
笔者 的 博客 (http:/www.ilinux.io ) 或 本 书 专用 的 GitHub 主 页 
Chttps:/github.com/ikubermetes ) 上 ， 欢 迎 读者 朋友 们 关注 并 留言 讨 
JE 已 ” 


对 于 具有 不 同 知识 基础 和 结构 的 读者 来 说， 仅 完 一 本 书 的 内 容 根 
本 不 足以 获取 所 需 的 全 部 信息 ， 大 家 还 可 以 通过 以 下 信息 获取 关于 


Kubernetes 系 统 的 更 多 资料 ， 本 书 在 写作 期 间 也 从 这 些 参考 资料 中 获 
得 了 很 大 的 帮助 。 


.Kubernetes Documentation 和 Kubernetes API Reference， 这 是 提供 
Kubernetes 领 域 相 关 知 识 最 全 面 、 最 深入 和 最 准确 的 参考 材料 。 

.《Kubernetes in Action》， 本 书 的 谋 篇 布局 及 写作 理念 与 此 书 不 
谋 而 合 ， 因 此 笔者 在 本 书 中 对 许多 概念 的 理解 和 验证 也 以 此 书 为 素 
材 ， 并 且 在 写作 之 时 有 多 处 概念 的 描述 也 借鉴 了 此 书 的 内 容 。 


:Red Hat Openshift Documentation ，Red Hat 公 司 的 产品 文档 规范 、 
权威 、 细 人 致 且 条 理 清晰 ， 是 不 可 多 得 的 参考 材料 。 


"The New Stack 的 技术 文章 及 调研 报告 是 了 解 Kubernetes 系 统 技术 
细 慷 和 行业 应 用 现状 及 趋势 的 不 可 多 得 的 优秀 资源 。 


.Bitmami 及 Heptio 站 后 上 的 博客 文章 提供 了 深入 了 解 和 学 习 
Kubermnetes 系 统 某 个 特定 技术 细 广 的 可 靠 资料 。 


另外 ， 本 书 还 大 量 借鉴 了 通过 搜索 引擎 所 获取 到 的 不 少 技术 文章 
和 参考 文档 ， 在 这 里 一 并 同 这 些 书籍 和 文章 的 作者 表示 深 深 的 谢意 ! 
致谢 


感谢 Kubernetes 社 区 创造 性 的 筋 动 成 果 和 和 将 付 出 ， 我 们 因此 有 
了 学 习 和 使 用 如 此 优秀 的 开源 系统 的 可 能 性 ， 这 也 是 本 书 得 以 编撰 的 


基 


感谢 我 的 同事 们 在 我 写作 期 间 给 予 的 文 持 和 理解 ， 他 们 的 努力 让 
我 拥有 了 得 以 放心 写作 的 时 间 和 精力 。 感 谢 提 供 了 相关 行业 信息 并 促 
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第 1 草 ”Kubernetes 系 统 基础 
近 十 几 年 来 ，IT 领 域 狐 技 术 、 新 概念 层出不穷 ， 例 如 DevOps、 微 


服务 (Microservice) 、 容 器 (Container) 、 云 计算 (Cloud 
Computing) 和 区 块 链 (Blockchain) 等 ， 直 有 “ 乱 花 渐 欲 迷人 有 眼 ? 之 
势 。 另 外 ， 出 于 业务 的 需要 ，IT 应 用 模型 也 在 不 断 地 变革 ， 例 如 ， 开 
发 模式 从 瀑布 式 (Waterfall) 到 敏捷 (Agile) 再 到 精益 (Lean) ， 甚 
至 是 与 QA 和 Operations 融 合 的 DevOps， 应 用 程序 架构 从 单 体 
(monolithic) 模型 到 分 层 模 型 再 到 微服 务 ， 部 署 及 打包 方式 从 面向 物 
理 机 到 虚拟 机 再 到 容器 ， 应 用 程序 的 基础 架构 从 目 建 机 房 到 托管 再 到 
云 计 算 ， 等 等 ， 这 些 变 革 使 得 I 技术 应 用 的 效率 大 大 提升 ， 同 时 却 以 
更 低 的 成 本 交付 更 高 质量 的 产品 。 


尤其 是 以 Docker 为 代表 的 容 右 技术 的 出 现 ， 终 结 了 DevOps 中 交付 
和 部 署 环 示 因 环境 、 配 置 及 程序 本 喘 的 不 同 而 造成 的 动 辑 几 种 甚至 十 
几 种 部 署 配 置 的 困境 ， 将 它们 统一 在 容器 镜像 (image) 之 上 。 如 今 ， 
越 来 越 多 的 企业 或 组 织 开始 选择 以 镜像 文件 作为 交付 载体 。 容 器 镜像 
之 内 直接 包含 了 应 用 程序 及 其 依赖 的 系统 环境 、 库 、 基 础 程序 等 ， 从 
而 能 够 在 容器 引擎 上 直接 运行 。 于 是 ，IT 运 维 工 程 师 (operator) 无 须 
关注 开发 应 用 程序 的 编程 语言 、 环 境 配置 等 ， 甚 至 过 业务 逻 辑 本 寻 也 
不 必 过 多 关注 ， 而 只 需要 掌握 容 絮 管理 的 单一 工具 链 即 可 。 


部 警 的 复杂 度 虽 然 降低 了 ， 但 以 容 需 格式 运行 的 应 用 程序 间 的 协 
同 却 成 了 一 个 新 的 到 待 解决 的 问题 ， 这 种 需求 在 微服 务 架 构 中 表现 得 
尤为 明显 。 结 果 ， 以 Kubernetes 为 代表 的 容器 编排 系统 应 需 而 生 。 


1.1 容器 技术 概述 


容器 是 一 种 轻 量 级 、 可 移植 、 自 包含 的 软件 打包 技术 ， 它 使 得 应 
用 程序 可 以 在 几乎 任何 地 方 以 相同 的 方式 运行 。 软 件 开 发 工程 师 在 自 
己 笔记 本 上 创建 并 测试 完成 的 容器 ， 无 须 任何 修改 就 能 够 在 生产 系统 
的 虚拟 机 、 物理 机 或 云 主机 上 运行 。 


容器 由 应 用 程序 本 身 和 它 的 环境 依赖 ( 库 和 其 他 应 用 程序 ) 两 部 
分 组 成 ， 并 在 宿主 机 (Host) 操作 系统 的 用 户 空 间 中 运行 ， 但 与 操作 
系统 的 其 他 进程 互相 隔离 ， 它 们 的 实现 机 制 有 别 于 诸如 VMWare、 
0 的 1-1 所 未 。 
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图 1-1 容 絮 和 虚拟 机 对 比 


(http://www.nuagenetworks.net/blog/containers/ ) 


由 于 同一 个 宾主 机 上 的 所 有 容器 都 共享 其 底层 操作 系统 (内 核 空 
间 ) ， 这 就 使 得 容器 在 体积 上 要 比 传统 的 虚拟 机 小 得 多 。 另 外 ， 局 动 
容器 无 须 启动 整个 操作 系统 ， 所 以 容器 部 署 和 启动 的 速度 更 快 ， 开 销 
0 也 更 容易 迁移 。 事 实 上 ， 容 器 赋予 了 应 用 程序 超 强 的 可 移植 能 


1.1.1 容器 技术 的 功用 


IT 系统 在 架构 上 已 经 迭代 数 十 年 之 久 ， 其 环境 复杂 程度 日 趋 加 
重 ， 直 有 积 重 难 返 之 势 。 现 如 今 ， 应 用 程序 开发 人 员 通 常 需要 同时 使 
用 多 种 服务 构建 ， 并 要 架构 IT 信息 系统 ， 涉 及 MQ、Cache 和 DB 等 ， 且 
很 可 能 要 部 署 到 不 同 的 环境 中 ， 如 物理 服务 器 、 虚 拟 服务 器 、 私 有 云 
或 公有 云 之 上 。 这 些 不 同 的 主机 或 许 还 有 着 不 同 的 系统 环境 ， 如 
RHEL 、Debian 或 SUSE 等 Linux 发 行 版 ， 甚 至 是 UNIX、Windows 等 。 


结果 ， 一 方面 应 用 程序 包含 了 多 种 服务 ， 每 种 服务 均 可 能 存在 依 
赖 的 库 和 软件 包 ; 男 一 方面 存在 多 种 部 闭环 境 ， 而 服务 在 运行 时 又 可 
能 需要 动态 迁移 到 不 同 的 环境 中 。 于 是 ， 各 种 服务 和 环境 通过 排列 组 
合 产生 了 一 个 大 部 姥 矩 阵 。 应 用 程序 开发 工程 师 在 编写 代码 时 需要 考 
虚 不 同 的 运行 环境 ， 而 运 维 工程 师 则 需要 为 不 同 的 服务 和 平台 配置 环 
境 。 对 他 们 双方 来 说 ， 这 痢 必 将 是 一 项 困难 而 艰巨 的 任务 。 


幸运 的 是 ， 货 运 系 统 的 集 流 箱 机 制 为 解决 这 个 难题 提供 了 有 效 的 
昔 鉴 方案 。Docker 正 是 将 集 奢 箱 思想 运用 到 软件 打包 上 ， 为 代码 提供 
了 一 个 基于 容器 的 标准 化 运输 系统 。Docker 可 以 将 几乎 任何 应 用 程序 
及 其 依赖 的 运行 环境 都 打包 成 一 个 轻 量 级 、 可 移植 、 目 包含 的 容器 ， 
并 能 够 运行 于 文 持 Docker 容 器 引 敬 的 所 有 操作 系统 之 上 。 们 言 之 ， 容 
妖 的 优势 主要 表现 在 以 下 两 个 方面 。 


.应 用 程序 开发 工程 师 : “一 次 构建 ， 到 处 运行 ”(Build Once，Run 
Anywhere) 。 容 器 意味 着 环境 隔离 和 可 重复 性 ， 开 发 人 员 只 需 为 应 用 
创建 一 个 运行 环境 ， 并 将 其 打包 成 容 絮 便 可 在 各 种 部 署 环境 上 运行 ， 
并 与 它 所 在 的 宿主 机 环境 隔离 。 


. 运 维 工程 师 : “一 次 配置 ， 运 行 所 有 ” (Configure Once，Run 
Anything) 。 一 旦 配置 好 标准 的 容器 运行 时 环境 ， 服 务 器 就 可 以 运行 
任何 容器 ， 这 使 得 运 维 人 员 的 工作 变 得 更 高 效 、 一 致 和 可 重复 。 容 器 
消除 了 开发 、 测 试 、 生 产 环境 的 不 一 致 性 。 


T12 和 雁 玲 向 更 


容器 技术 的 概念 最 初出 现在 2000 年 ， 当 时 称 为 FreeBSD jail， 这 种 
技术 可 将 FreeBSD 系 统 分 区 为 多 个 子 系统 〈 也 称 为 Jail) 。2001 年 ， 通 
过 Jacques Gklinas 的 VServer 项 目 ， 隅 离 环 境 的 实施 理念 进入 了 Linux 领 


域 。 


Ti 


Jail 的 目的 是 让 进程 在 经 过 修改 的 chroot 环 境 中 创建 ， 而 不 会 脱离 
和 影响 整个 系统 一 chroot 环 境 对 文件 系统 、 网 络 和 用 户 的 访问 都 实现 
了 虚拟 化 。 然 而 ，Jail 在 实施 方面 存在 着 不 少 的 局 限 性 ， 当 它 与 
Namespaces 和 CGroups 等 技术 结合 在 一 起 之 后 ， 才 让 这 种 隅 离 方 法 从 
构想 变 为 了 现实 。 后 来 ，Linux 容 器 项 目 (LXC) 又 为 其 添加 了 一 些 用 
户 常 用 的 工具 、 模 板 、 库 和 语言 绑 定 ， 从 而 较 好 地 改善 了 用 户 使 用 容 
器 技术 时 的 体验 。 


Docker 在 LXC 项 目的 基础 上 ， 从 文件 系统 、 网 络 互 联 到 进程 隅 离 
等 方面 对 容 妮 技术 进行 了 进一步 的 封装 ， 极 大 地 简化 了 容器 的 创建 和 
维护 过 程 ， 从 而 促进 了 容 絮 技术 的 大 流行 。Docker 最 初 是 由 dotCloud 
公司 创始 人 Solomon Hykes 在 法 国 期 间 发 起 的 一 个 公司 内 部 项 目 ， 并 于 
2013 年 3 月 以 Apache 2.0 授 权 协 议 开 源 ， 其 项 目 代 码 托 管 于 GitHub 之 
上 。 虽 然 其 最 初 的 实现 是 基于 LXC 项 目的 ， 但 Docker 在 后 来 的 0.7 版 本 
转 为 使 用 自行 开发 的 libcontainer 容 器 引 警 ， 而 1.11 版 本 又 将 其 换 作 了 


runnC 和 和 containerd 。 


@ 提示 。 在 2017 年 4 月 举行 的 DockerCon 上 ，Docker 公 司 将 
GitHub 上 原本 隶属 于 Docker 组 织 的 Docker 项 目 直接 转移 到 了 一 个 新 的 
名 为 Moby 的 组 织 下 ， 并 将 其 重 命名 为 Moby 项 目 。 


1.1.3 ”Docker 的 功能 限制 


Docker 本 映 非 第 运 合 用 于 管理 单个 容 右 ， 不 过 ， 一 旦 开始 使 用 越 
来 越 多 的 容器 封 效 和 运行 应 用 程序 ， 必 将 会 导致 其 管理 和 编排 变 得 越 
来 越 困难 。 最 终 ， 用 户 不 得 不 对 容器 实施 分 组 ， 以 便 跨 所 有 容 屁 提供 
网 络 、 安 全 、 监控 等 服务 。 于 是 ， 以 Kubernetes 为 代表 的 容器 编排 系统 
应 运 而 生 。 


真正 的 生产 型 应 用 会 涉及 多 个 容器 ， 这 些 容器 必须 跨 多 个 服务 器 
主机 进行 部 署 。Kubernetes 可 以 提供 所 需 的 编排 和 管理 功能 ， 以 便 用 户 
针对 这 些 工 作 负 载 轻松 完成 大 规模 容器 部 署 。 而 且 ， 借 助 于 Kubernetes 
的 编排 功能 ， 用 户 可 以 构建 出 跨 多 个 容器 的 应 用 服务 ， 并 且 可 以 实现 
跨 集群 调度 、 扩 展 容 器 ， 以 及 长 期 持续 管理 这 些 容 器 的 健康 状况 等 。 
使 用 中 ，Kubernetes 还 需要 与 网 络 、 存 储 、 安 全 性 、 监 控 及 其 他 服务 进 
行 整合 ， 以 提供 全 面 的 容器 基础 架构 ， 如 图 1-2 所 示 。 
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图 1-2 ”容器 与 容器 编排 (来 源 ，RedHat Inc.) 


Kubernetes 利 用 容器 的 扩 缩 容 机 制 解决 了 许多 常见 的 问题 ， 它 将 容 
句 归 类 到 一 起 ， 形 成 “容器 集 ” (Pod) ， 为 分 组 的 容器 增加 了 一 个 抽象 
层 ， 用 于 帮助 用 户 调度 工作 负载 (workload) ， 并 为 这 些 容器 提供 所 需 
的 联网 和 存储 等 服务 。Kubernetes 的 其 他 部 分 可 帮助 用 户 在 这 些 Pod 之 
0 ， 同 时 确保 运行 正确 数量 的 容器 ， 以 充分 支持 实际 的 
工作 人 负载。 


1.2 ”Kubernetes 概 壕 


尽管 公开 面世 不 过 短 短 数 年 时 间 ，Kubernetes 业 已 成 为 容 絮 编排 
领域 事实 上 的 标准 ， 其 近 一 两 年 的 发 展 状 态 也 在 不 断 地 验证 着 Urs 
Hlzle 兽 经 的 断言 : 无 论 是 公有 云 、 私 有 云 抑或 混合 云 ，Kubernetes 都 
将 作为 一 个 为 任何 应 用 、 任 何 环境 提供 的 容 喜 管理 框架 而 无 处 不 在 。 


1.2.1 Kubernetes 人 和 位 史 


Kubernetes (来 自 希 腊 语 ， 意 为 “舵手 ”或 “飞行 员 *) 由 Joe Beda、 
Brendan Bums 和 Craig McLuckie 创 立 ， 而 后 Google 的 其 他 几 位 工程 
师 ， 包 括 Brian Grant 和 Tim Hockin 等 加 盟 共 同 研发 ， 并 由 Google 在 2014 
年 下 次 对 外 宣布 。Kubermetes 的 开发 和 设计 都 深 受 Google 内 部 系统 Borg 
的 影响 ， 事 实 上 ， 它 的 许多 顶级 贡献 者 之 前 也 是 Borg 系 统 的 开发 者 。 


Borg 是 Google 内 部 使 用 的 大 规模 集群 管理 系统 ， 久 人 负 盛 名 。 它 建 
构 于 容器 技术 之 上 ， 目 的 是 实现 资源 管理 的 自动化， 以 及 跨 多 个 数据 
中 心 的 资源 利用 率 最 大 化 。2015 年 4 月 ，Borg 论 文 《Large-scale cluster 
management at Google with Borg》 伴 随 Kubernetes 的 高 调 宣传 被 Google 
首次 公开 ， 人 们 终于 有 绿 得 宁 其 全 貌 。 


事实 上 ， 正 是 由 于 诞生 于 容 需 世家 Google， 并 站 在 Borg 这 个 巨人 
的 肩膀 之 上 ， 充 分 受益 于 Borg 过 去 十 数 年 间 积累 的 经 验 和 教训 ， 
Kubernetes 甫 一 面世 丈 立 即 广 受 关 注 和 青睐 ， 并 迅速 称霸 了 容器 编排 
技术 领域 。 很 多 人 将 Kubernetes 视 为 Borg 系 统 的 一 个 开源 实现 版 本 ， 在 
Google 内 部 ，Kubernetes 的 原始 代号 曾经 是 Serven of Nine， 即 星际 迷 
航 中 友好 的 “Borg” 角 色 ， 它 标识 中 的 舵 轮 有 七 个 轮 辐 就 是 对 该 项 目 代 
号 的 致意 ， 如 图 1-3 所 示 。 


图 1-3 Kubernetes Logo 


Kubernetes v1.0 于 2015 年 7 月 21 日 发 布 ， 紧 随 其 后 ，Google 与 Linux 
基金 会 合作 组 建 了 Cloud Native Computing Foundation ( 云 原生 计算 基 
金 会 ， 人 简称 为 CNCF) ， 并 将 Kubernetes 作 为 种 子 技术 予以 提供 。 这 之 
后 ，Kubermmetes 进 入 了 版 本 快速 迭代 期 ， 从 此 不 断 地 融入 着 新 功能 ， 

如 Federation、Network Policy API、RBAC、CRD 和 CSI， 等 等 ， 并 增 
加 了 对 Windows 系 统 的 支持 。 


2017 年 可 谓 是 容器 生态 发 展 史 上 具有 里 程 碑 意 义 的 一 年 。 这 一 

年 ，AWS、Azure 和 Alibaba Cloud 都 相继 在 其 原 有 容器 服务 上 新 增 了 对 
Kubernetes 的 文 持 ， 而 Docker 官 方 也 在 2017 年 10 月 宣布 同时 文 持 Swarm 
和 Kubernetes 编 排 系 统 。 这 一 年 ，RKT 容 需 派 系 的 CoreOS 人 舍弃 掉 目 己 
的 调度 工具 Fleet， 将 其 商用 平台 Tectonic 的 重心 转移 至 Kubernetes。 这 
一 年 ，Mesos 也 于 9 月 宣布 了 对 Kubernetes 的 支持 ， 其 平台 用 户 可 以 安 
装 、 扩 展 和 升级 多 个 生产 级 的 Kubernetes 集 群 。 这 一 年 ，Rancher Labs 
推出 了 其 2.0 版 本 的 容器 管理 平台 并 宣布 all-in Kubermetes， 放 弃 了 其 内 
置 多 年 的 容 絮 编排 系统 Cattle。 类 似 的 故事 依然 在 进行 ， 并 且 必 将 在 一 
个 时 期 内 持续 上 演 。 


1.2.2 ”Kubernetes 特 性 


Kubernetes 是 一 种 用 于 在 一 组 主机 上 运行 和 协同 容 妮 化 应 用 程序 
的 系统 ， 则 在 提供 可 预测 性 、 可 扩展 性 与 高 可 用 性 的 方法 来 完全 管理 
容器 化 应 用 程序 和 服务 的 生命 周期 的 平台 。 用 户 可 以 定义 应 用 程序 的 
运行 方式 ， 以 及 与 其 他 应 用 程序 或 外 部 世界 交互 的 途径 ， 并 能 实现 服 
务 的 扩容 和 缩 容 ， 执 行 平滑 深 动 更 新 ， 以 及 在 不 同 版 本 的 应 用 程序 之 
则 调度 流量 以 测试 功能 或 回 深 有 问题 的 部 署 。Kubernetes 提 供 了 接口 
和 可 组 合 的 平台 原 语 ， 使 得 用 户 能 够 以 高 度 的 灵活 性 和 可 靠 性 定义 及 
管理 应 用 程序 。 简 单 总 结 起 来 ， 它 具有 以 下 几 个 重要 特性 。 


(1) 目 动 装 箱 

建构 于 容器 之 上 ， 基 于 资源 依赖 及 其 他 约束 目 动 完成 容 右 部 署 且 
不 影响 其 可 用 性 ， 并 通过 调度 机 制 混合 关键 型 应 用 和 非 关 键 型 应 用 的 
工作 人 负载 于 同一 节操 以 提升 资源 利用 率 。 

(2) 目 我 修复 〈 自 您) 

文 持 容 万 故 障 后 目 动 重 局 、 丰 点 故障 后 重新 调度 容 希 ， 以 及 其 他 
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(3) 水 平 扩展 


支持 通过 人 简单 命令 或 UI 手动 水 平 扩 展 ， 以 及 基于 CPU 等 资源 负载 
率 的 目 动 水 平 扩展 机 制 。 
(4) 服务 发 现 和 负载 均衡 
Kubemetes 通 过 其 附加 组 件 之 一 的 KubeDNS (或 CoreDNS) 为 系 
统 内 置 了 服务 发 现 功 能 ， 它 会 为 每 个 Service 配 置 DNS 名 称 ， 并 人 允许 集 
群 内 的 客户 端 直 接 使 用 此 名 称 发 出 访问 请 求 ， 而 Service 则 通过 iptables 
或 ipvs 内 建 了 负载 均衡 机 制 。 


(5) 自动 发 布 和 回 深 


Kubemetes 文 持 “ 灰 度 ” 更 新 应 用 程序 或 其 配置 信息 ， 它 会 监控 更 新 
过 程 中 应 用 程序 的 健康 状态 ， 以 确保 它 不 会 在 同一 时 刻 杀 挥 所 有 实 
例 ， 而 此 过 程 中 一 旦 有 故障 发 生 ， 就 会 立即 自动 执行 回 深 操 作 。 


(6) 密 钥 和 配置 管理 


Kubernetes 的 ConfigMap 实 现 了 配置 数据 与 Docker 镜 像 解 稍 ， 需 要 
时 ， 仅 对 配置 做 出 变更 而 无 须 重新 构建 Docker 镜 像 ， 这 为 应 用 开发 部 
署 带 来 了 很 大 的 灵活 性 。 此 外 ， 对 于 应 用 所 依赖 的 一 些 敏 感 数据 ， 如 
用 户 名 和 密码 、 令 牌 、 密 钥 等 信息 ，Kuberetes 专 门 提 供 了 Secret 对 和 象 
为 其 角 竺 ， 颗 便利 了 应 用 的 快速 开 发 和 交付 ， 又 提供 了 一 定 程度 上 的 
安全 保障 。 


(7) 存储 编排 
Kubernetes 文 持 Pod 对 和 象 按 需 目 动 挂 载 不 同类 型 的 存储 系统 ， 这 人 包 
括 下 点 本 地 存储 、 公 有 云 服务 商 的 云 存储 (如 AWS 和 GCP 等 ) ， 以 及 


网 络 存储 系统 (例如 ，NFS 、iSCSI、GlusterFS、Ceph、Cinder 和 
Flocker 等 ) 。 


(8) 批量 处 理 执行 


除了 服务 型 应 用 ，Kubernetes 还 文 持 批 处 理 作业 及 CI (持续 集 
成 ) ， 如 果 需 要 ， 一 样 可 以 实现 容器 故障 后 恢复 。 


1.2.3 Kubernetes 概 念 和 术语 


Kubernetes 使 用 共享 网 络 将 多 个 物理 机 或 虚拟 机 汇集 到 一 个 集群 
中 ， 在 各 服务 器 之 间 进 行 通 信 ， 该 集群 是 配置 Kubernetes 的 所 有 组 件 、 
功能 和 工作 负载 的 物理 平台 。 集 群 中 一 台 服 务 器 (或 高 可 用 部 署 中 的 
一 组 服务 器 ) 用 作 Master， 负 责 管理 整个 集群 ， 余 下 的 其 他 机 器 用 作 
Worker Node 〈 早 期 版 本 中 也 称 为 Minion) ， 它 们 是 使 用 本 地 和 外 部 资 
源 接收 和 运行 工作 负载 的 服务 器 ， 如 图 1-4 所 示 。 集 群 中 的 这 些 主机 可 
以 是 物理 服务 器 ， 也 可 以 是 虚拟 机 〈 包 括 Iaas 云 端的 VPS) 。 
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Masters 
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图 1-4 Kubernetes 集 群 主 机 


(1) Master 


Master 是 集群 的 网 关 和 中 枢 ， 负 责 诸如 为 用 户 和 容 户 端 骏 露 API、 
跟踪 其 他 服务 器 的 健康 状态 、 以 最 优 方式 调度 工作 负载 ， 以 及 编排 其 
他 组 件 之 间 的 通信 等 任务 ， 它 是 用 户 或 客户 端 与 集群 之 则 的 核心 联络 
点 ， 并 负责 Kubernetes 系 统 的 大 多 数 集 中 式 管 探 逻辑 。 单 个 Master 末 点 
即 可 完成 其 所 有 的 功能 ， 但 出 于 元 余 及 负载 均衡 等 目的 ， 生 产 环境 中 
通常 需要 协同 部 署 多 个 此 类 主机 。Master 节 点 类 似 于 蜂 群 中 的 蜂王 。 


(2) Node 


Node 是 Kubernetes 集 群 的 工作 节点 ， 负 责 接收 来 目 Master 的 工作 指 
令 并 根据 指令 相应 地 创建 或 销毁 Pod 对 象 ， 以 及 调整 网 络 规则 以 合理 地 
路 由 和 转发 流量 等 。 理 论 上 讲 ，Node 可 以 是 任何 形式 的 计算 设备 ， 不 
过 Master 会 统一 将 其 抽象 为 Node 对 象 进行 管理 。 Node 类 似 于 蜂 群 中 的 
工蜂 ， 生 产 环境 中 ， 它 们 通常 数量 众多 。 


Kubernetes 将 所 有 Node 的 资源 集结 于 一 处 形成 一 人 台 更 加 强大 的 “ 服 
务 器 ”"， 如 图 1-5 所 示 ， 在 用 户 将 应 用 部 署 于 其 上 时 ，Master 会 使 用 调度 
算法 将 其 自动 指派 至 某 个 特定 的 Node 运 行 。 在 Node 加 入 集群 或 从 集群 
中 移 除 时 ，Master 也 会 按 需 重新 编排 影响 到 的 Pod 〈 容 器 ) 。 于 是 ， 用 
户 无 须 关 心 其 应 用 究竟 运行 于 何 处 。 


nodel 


nodeN 
cpu: 4 


ram: 16 


图 1-5 Node 组 成 的 虚拟 资源 池 


从 抽象 的 视角 来 讲 ，Kubernetes 还 有 着 众多 的 组 件 来 文 撑 其 内 部 的 
业务 逻辑 ， 包 括 运行 应 用 、 应 用 编排 、 服 务 骏 露 、 应 用 恢复 等 ， 它 们 
在 Kubemetes 中 被 抽象 为 Pod、Service、Controller 等 资源 类 型 ， 下 面 列 
出 了 几 个 较为 常用 的 资源 抽象 。 


(1) Pod 


Kubernetes 并 不 直接 运行 容 絮 ， 而 是 使 用 一 个 抽象 的 资源 对 和 象 来 在 
装 一 个 或 者 多 个 容器 ， 这 个 抽象 即 为 Pod， 它 也 是 Kubernetes 的 最 小 调 
度 单 元 。 同 一 Pod 中 的 容器 共享 网 络 名 称 空间 和 存储 资源 ， 这 些 容器 可 
经 由 本 地 回环 和 口 lo 直 接 通 信 ， 但 彼此 之 间 又 在 Mount、User 及 PID 等 
名 称 空 间 上 保持 了 隔离 。 尽 管 Pod 中 可 以 包含 多 个 容器 ， 但 是 作为 最 小 
调度 单元 ， 它 应 该 尽 可 能 地 保持 “小 ”"， 即 通常 只 应 该 包含 一 个 主 容 
器 ， 以 及 必要 的 辅助 型 容器 (sidecar) ， 如 图 1-6 所 示 。 
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图 1-6 ”Kubernetes Pod 示 意图 


(2) 资源 标签 


标签 (Label) 是 将 资源 进行 分 类 的 标识 符 ， 资 源 标 签 其 实 就 是 一 
个 键 值 型 (key/values) 数据 。 标 签 旨 在 指定 对 象 (如 Pod 等 ) 辨识 性 的 
属性 ， 这 些 属 性 仅 对 用 户 存 在 特定 的 意义 ， 对 Kubernetes 集 群 来 说 并 不 
直接 表达 核心 系统 语义 。 标 签 可 以 在 对 象 创建 时 附加 其 上 ， 并 能 够 在 
创建 后 的 任意 时 间 进 行 添 加 和 修改 。 一 个 对 象 可 以 拥有 多 个 标签 ， 一 
个 标签 也 可 以 附加 于 多 个 对 象 (通常 是 同一 类 对 象 ) 之 上 ， 如 图 1-7 所 
示 “。 
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release: beta release: canary 


env: production env: production 
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图 1-7 ”Kubernetes 资 源 标签 
(3) 标签 选择 器 
标签 选择 器 (Selector) 全 称 为 “Label Selector”， 它 是 一 种 根据 
Label 来 过 滤 符 合 条 件 的 贷 源 对 象 的 机 制 。 例 如 ， 将 附 有 标签 “role: 
backend” 的 所 有 Pod 对 象 挑选 出 来 归 为 一 组 就 是 标签 选择 器 的 一 种 应 


用 ， 如 图 1-8 所 示 。 用 户 通常 使 用 标签 对 资源 对 和 象 进行 分 类 ， 而 后 使 用 
标签 选择 右 挑 选 出 它们 ， 例 如 将 其 创建 为 某 Service 的 端点 。 


Pod role: backend 


role: backend 


label 
selector 


matchLables: 
role: backend 


Pod role: backend 


图 1-8 ”标签 选择 器 


(4) Pod 控 制 器 


尽管 Pod 是 Kubernetes 的 最 小 调度 单元 ， 但 用 户 通 常 并 不 会 直接 部 
署 及 管理 Pod 对 象 ， 而 是 要 借助 于 另 一 类 抽象 一 控制 器 (Controller) 对 
其 进行 管理 。 用 于 工作 负载 的 控制 絮 是 一 种 管理 Pod 生 命 周 期 的 资源 抽 


象 ， 它 们 是 Kubernetes 上 的 一 类 对 象 ， 而 非 单个 资源 对 象 ， 包 括 
ReplicationController 、 ReplicaSet、 Deployment、StatefulSet、Job 等 。 以 
图 1-9 中 所 示 的 Deployment 探 制 硕 为 例 ， 它 负责 确保 指定 的 Pod 对 象 的 副 
本 数量 精确 符合 定义 ， 否 则 “多 退 少 补 ”。 使 用 控制 锅 之 后 区 不 再 需要 
手动 管理 Pod 对 象 了 ， 用 户 只 需要 声明 应 用 的 期 望 状态 ， 控 制 絮 就 会 自 
动 对 其 进行 进程 管理 。 


Master : Nodes 


Deployment | 


replicas: 3 [~ Pod role: backend 


label | matchLables: Wo 
selector role: backend 党 od a 


Pod role: backend 


图 1-9” Deployment 控制 器 示意 图 
(5) 服务 资源 (Service) 


Service 是 建立 在 一 组 Pod 对 象 之 上 的 资源 抽象 ， 它 通过 标签 选择 器 

选 定 一 组 Pod 对 象 ， 并 为 这 组 Pod 对 象 定义 一 个 统一 的 固定 访问 入 口 
(通常 是 一 个 IP 地 址 ) ， 知 Kubernetes 集 群 存在 DNS 附件 ， 它 就 会 在 
Service 创 建 时 为 其 自动 配置 一 个 DNS 名 称 以 便 客 户 端 进行 服务 发 现 。 
到 达 Service 了 的 请 求 将 被 负载 均衡 至 其 后 的 端点 一 各 个 Pod 对 象 之 上 ， 
因此 Service 从 本 质 上 来 讲 是 一 个 四 层 代 理 服 务 。 另 外 ，Service 还 可 以 
将 集群 外 部 流量 引入 到 集群 中 来 。 
(6) 存储 卷 

存储 卷 (Volume) 是 独立 于 容器 文件 系统 之 外 的 存储 空间 ， 常 用 

于 扩展 容 絮 的 存储 空间 并 为 它 提供 持久 存储 能 力 。Kubernetes 集 群 上 的 


存储 卷 大 体 可 分 为 临时 卷 、 本 地 卷 和 网 络 卷 。 临 时 卷 和 本 地 卷 都 位 于 
Node 本 地 ， 一 旦 Pod 被 调度 至 其 他 Node， 此 种 类 型 的 存储 卷 将 无 法 访 


问 到 ， 因 此 临时 卷 和 本 地 卷 通常 用 于 数据 缓存 ， 持 和 久 化 的 数据 则 需要 
放置 于 持久 卷 (persistent volume) 之 上 。 


(7) Name 和 Namespace 


名 称 (Name) 是 Kubernetes 集 群 中 资源 对 象 的 标识 符 ， 它 们 的 作 
用 域 通常 是 名 称 空间 (Namespace) ， 因 此 名 称 空间 是 名 称 的 额外 的 限 
定 机 制 。 在 同一 个 名 称 空 间 中 ， 同 一 类 型 资产 对 象 的 名 称 必 须 具 有 唯 
一 性 。 名 称 空间 通常 用 于 实现 租 尸 或 项 目的 资源 隔离 ， 从 而 形成 逻辑 
分 组 ， 如 图 1-10 所 示 。 创 建 的 Pod 和 Service 等 资源 对 象 都 属于 名 称 空 间 
级 别 ， 示 指定 时 ， 它 们 都 属于 默认 的 名 称 空 间 “default”。 
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图 1-10 ”名称 空间 
(8) Annotation 


Annotation (注解 ) 是 另 一 种 附加 在 对 象 之 上 的 键 值 类 型 的 数据 ， 

但 它 拥有 更 大 的 数据 容量 。Annotation 常 用 于 将 各 种 非 标 识 型 元 数据 
(metadata) 附加 到 对 象 上 ， 但 它 不 能 用 于 标识 和 选择 对 象 ， 通 党 也 不 
会 役 Kubernetes 直 接合 用 ， 其 主要 目的 是 方便 工具 或 用 户 的 阅读 及 查找 


(9) Ingress 


Kubernetes 将 Pod 对 象 和 外 部 网 络 环境 进行 了 隔离 ，Pod 和 Service 等 
对 象 间 的 通信 都 使 用 其 内 部 专用 地 址 进行 ， 如 若 需 要 开放 某 些 Pod 对 和 象 
提供 给 外 部 用 户 访 问 ， 则 需要 为 其 请 求 流量 打开 一 个 通 往 Kubernetes 集 
群 内 部 的 通道 ， 除 了 Service 之 外 ，Ingress 也 是 这 类 通道 的 实现 方式 之 


1.3 Kubernetes 集 群 组 件 


一 个 典型 的 Kubernetes 集 群 由 多 个 工作 节点 (worker node) 和 一 
个 集群 控制 平面 (control plane， 即 Master) ， 以 及 一 个 集群 状态 存储 
系统 (etcd) 组 成 。 其 中 Master 节 点 负责 整个 集群 的 管理 工作 ， 为 集群 
提供 管理 接口 ， 并 监控 和 编排 集群 中 的 各 个 工作 和 点 。 各 万 点 负责 以 
Pod 的 形式 运行 容器 ， 因 此 ， 各 市 点 需要 事先 配置 好 容 妮 运行 依赖 到 
的 所 有 服务 和 资源 ， 如 容器 运行 时 环境 等 。Kubernetes 的 系统 架构 如 
图 1-11 所 示 。 


Master 妆 点 主要 由 apiserver、controller-manager 和 scheduler 三 个 组 
件 ， 以 及 一 个 用 于 集群 状态 存储 的 etcd 存 储 服务 组 成 ， 而 每 个 Node 节 
点 则 主要 包含 kubelet、kube-proxy 及 容 属 引擎 (Docker 是 最 为 常用 的 实 
现 ) 等 组 件 。 此 外 ， 完 整 的 集群 服务 还 依赖 于 一 些 附加 组 件 ， 如 
KubeDNS 等 。 


1.3.1 Master 组件 


Kubernetes 的 集群 控制 平面 由 多 个 组 件 组 成 ， 这 些 组 件 可 统一 运行 
于 单一 Master 玉 点， 也 可 以 以 多 副本 的 方式 同时 运行 于 多 个 市 点 ， 以 为 
Master 提 供 高 可 用 功能 ， 其 至 还 可 以 运行 于 Kubernetes 集 群 自身 之 上 。 
Master 主 要 包含 以 下 几 个 组 件 。 


' Kubernetes Cluster ' kube-system namespace 


Master 


kube-proxy 


图 1-11 Kubernetes 系 统 组 件 
(1) API Server 
API Server 人 负责 输 出 RESTful 风 格 的 Kubernetes API， 它 是 发 往 集 群 
的 所 有 REST 操 作 命 令 的 接 入 点 ， 并 负责 接收 、 校 验 并 响应 所 有 的 
REST 请 求 ， 结 果 状 态 被 持久 存储 于 etcd 中 。 因 此 ，API Server 是 整个 集 
群 的 网 关 。 


(2) 集群 状态 存储 (Cluster State Store) 


Kubernetes 集 群 的 所 有 状态 信息 都 需要 持久 存储 于 存储 系统 etcd 
中 ， 不 过 ，etcd 是 由 CoreOS 基 于 Raft 协 议 开发 的 分 布 式 键 值 存储 ， 可 用 
于 服务 发 现 、 共 享 配置 以 及 一 致 性 保障 (如 数据 库 主 节点 选择 、 分 布 
式 锁 等 ) 。 因 此 ，etcd 是 独立 的 服务 组 件 ， 并 不 隶属 于 Kubernetes 集 群 
目 身 。 生 产 环境 中 应 该 以 etcd 集 群 的 方式 运行 以 确保 其 服务 可 用 性 。 


etcd 不 仅 能 够 提供 键 值 数据 存储 ， 而 且 还 为 其 提供 了 监听 
(watch) 机 制 ， 用 于 监听 和 推送 变更 。Kubernetes 集 群 系统 中 ，etcd 中 
的 键 值 发 生变 化 时 会 通知 到 API Server， 并 由 其 通过 watch API 回 客户 端 
输出。 基于 watch 机 制 ，Kubernetes 集 群 的 各 组 件 实现 了 高 效 协同 。 


(3) 控制 器 管理 器 (Controller Manager) 


Kubernetes 中 ， 集 群 级 别 的 大 多 数 功能 都 是 由 几 个 被 称 为 控制 絮 的 
进程 执行 实现 的 ， 这 几 个 进程 被 集成 于 kube-controller-manager 守 护 进 
0 具 
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:生命 周期 功能 包括 Namespace 创 建 和 生命 周期 、Event 垃 圾 回 
收 、Pod 终 止 相关 的 垃圾 回收 、 级 联 垃圾 回收 及 Node 二 圾 回收 等 。 


API 业务 逻 辑 : 例如 ， 由 ReplicaSet 执 行 的 Pod 扩 展 等 。 
(4) 调度 器 (Scheduler) 


Kubernetes 是 用 于 部 署 和 管理 大 规模 容器 应 用 的 平台 ， 根 据 集 群 规 
模 的 不 同 ， 其 托管 运行 的 容 妮 很 可 能 会 数 以 干 计 其 至 更 多 。API Server 
确认 Pod 对 象 的 创建 请 求 之 后 ， 便 需要 由 Scheduler 根 据 集 群 内 各 节点 的 
可 用 资源 状态 ， 以 及 要 运行 的 容器 的 资源 需求 做 出 调度 决策 ， 其 工作 
逻辑 如 图 1-12 所 示 。 男 外 ，Kubernetes 还 支持 用 户 自 定 义 调度 器 。 


焦作 
图 1-12 ”Kubernetes 调 度 器 


1.3.2 Node 组 件 


Node 负 责 提 供 运 行 容器 的 各 种 依赖 环境 ， 并 接受 Master 的 管理 。 
每 个 Node 主 要 由 以 下 几 个 组 件 构成 。 


(1) Node 的 核心 代理 程序 kubelet 


kubelet 是 运行 于 工作 节点 之 上 的 守护 进程 ， 它 从 API Server 接 收 天 
于 Pod 对 象 的 配置 信息 并 确保 它们 处 于 期 望 的 状态 (desired state， 后 文 
不 加 区 别 地 称 之 为 “目标 状态 ”) 。kubelet 会 在 API Server 上 注册 当前 工 
作 节 点 ， 定 期 间 Master 汇 报 世 点 资源 使 用 情况 ， 并 通过 cAdvisor 监 探 容 
俐 和 市 点 的 资源 占用 状况 。 


(2) 容器 运行 时 环境 


每 个 Node 都 要 提供 一 个 容器 运行 时 (Container Runtime) 环境 ， 
它 负 足下 载 镜 像 并 运行 容器 。kubelet 并 未 固定 链接 至 某 容器 运行 时 环 
境 ， 而 是 以 插件 的 方式 载 入 配置 的 容 右 环境。 这 种 方式 清晰 地 定义 了 
各 组 件 的 边界 。 目 前 ，Kubemetes 支 持 的 容器 运行 环境 至 少 包 括 
Docker、RKT、cri-o 和 Fraki 等 。 


(3) kube-proxy 


每 个 工作 市 点 都 需要 运行 一 个 kube-proxy 守 护 进程 ， 它 能 够 按 需 
为 Service 资 源 对 象 生成 iptables 或 ipvs 规 则 ， 从 而 捕获 访问 当前 Service 
的 ClusterIP 的 流量 并 将 其 转发 至 正确 的 后 端 Pod 对 象 。 


1.3.3 ”核心 附件 


Kubemetes 集 群 还 依赖 于 一 组 称 为 “附件 ”(add-ons) 的 组 件 以 提 
供 完 整 的 功能 ， 它 们 通常 是 由 第 三 方 提供 的 特定 应 用 程序 ， 且 托管 运 
行 于 Kubernetes 集 群 之 上 ， 如 图 1-11 所 示 。 下 面 列 出 的 几 个 附件 各 目 为 
集群 从 不 同 角度 引用 了 所 需 的 核心 功能 。 


KubeDNS: 在 Kubernetes 集 群 中 调度 运行 提供 DNS 服务 的 Pod， 同 
一 集群 中 的 其 他 Pod 可 使 用 此 DNS 服务 解雇 主机 名。Kubernetes 目 1.11 
版 本 开始 默认 使 用 CoreDNS 项 目 为 集群 提供 服务 注册 和 服务 发 现 的 动 
态 名 称 解 析 服 务 ， 之 前 的 版 本 中 用 到 的 是 kube-dns 项 目 ， 而 SkyDNS 则 
是 更 早 一 代 的 项 目 。 


.Kubernetes Dashboard: Kubernetes 集 群 的 全 部 功能 都 要 基于 Web 
的 UI， 来 管理 集群 中 的 应 用 甚至 是 集群 自身 。 


.Heapster: 容器 和 节点 的 性 能 监控 与 分 析 系统 ， 它 收集 并 解析 多 
种 指标 数据 ， 如 资源 利用 率 、 和 生命 周期 事件 等 。 新 版 本 的 Kubernetes 
中 ， 其 功能 会 逐渐 由 Prometheus 结 合 其 他 组 件 所 取代 。 


.Ingress Controller: Service 是 一 种 工作 于 传统 层 的 负载 均衡 器 ， 而 
Ingress 是 在 应 用 层 实 现 的 HITP (s) 负载 均衡 机 制 。 不 过 ，Ingress 资 
源 目 吴 并 不 能 进行 “流量 穿 透 ">， 它 仅 是 一 组 路 由 规则 的 集合 ， 这 些 规 
则 需要 通过 Ingress 控 制 器 (Ingress Controller) 发 挥 作用 。 目 前 ， 此 类 
的 可 用 项 目 有 Nginx、Traefik、Envoy 及 HAProxy 等 。 


1.4 Kubernetes 网 络 模 型 基础 


云 计 算 的 核心 是 虚拟 化 技术 ， 网 络 虚 拟 化 技术 又 征 其 最 重要 的 组 
成 部 分 ， 用 于 在 物理 网 络 上 虚拟 多 个 相互 隔离 的 虚拟 网 络 ， 实 现 网 络 
资源 切片 ， 提 高 网 络 资源 利用 率 ， 实 现 弹性 化 网 络 。Kubernetes 作 为 
容器 云 技术 栈 中 的 容器 编排 组 件 ， 必 然 需 要 在 多 租户 (名 称 空间 ) 的 
基础 上 实现 弹性 网 络 管理 ， 这 也 是 “基础 设施 即 代码 ”的 要 求 之 一 。 


1.4.1 网络 模 型 概述 


Kubernetes 的 网 络 中 主要 存在 四 种 类 型 的 通信 : 同一 Pod 内 的 容 妖 
间 通 信 、 各 Pod 彼 此 之 间 的 通信 、Pod 与 Service 间 的 通信 ， 以 及 集群 外 
部 的 流量 同 Service 之 间 的 通信 。Kubernetes 为 Pod 和 Service 资 源 对 象 分 
别 使 用 了 各 目的 专用 网 络 ，Pod 网 络 由 Kubernetes 的 网 络 插 件 配置 实 
现 ， 而 Service 的 网 络 则 由 Kubernetes 集 群 予 以 指定 。 为 了 提供 更 灵活 的 
解决 方式 ，Kubernetes 的 网 络 模 型 需要 借助 于 外 部 插件 实现 ， 它 要 求 任 
何 实现 机 制 都 必须 满足 以 下 需求 。 


.所 有 Pod 间 均 可 不 经 NAT 机 制 而 直接 通信 。 
.所 有 节点 均 可 不 经 NAT 机 制 而 直接 与 所 有 容器 通信 。 


. 容 需 上 自己 使 用 的 卫 也 是 其 他 容器 或 节点 直接 看 到 的 地 址 。 换 句 话 
人 同一 平面 网 络 中 ， 而 且 可 以 使 用 Pod 自 屿 的 地 
妇 机 恒 ° 


Kubernetes 使 用 的 网 络 插件 必须 能 为 Pod 提 供 满 足以 上 要 求 的 网 
络 ， 它 需要 为 每 个 Pod 配 置 至 少 一 个 特定 的 地 址 ， 即 Pod IP。Pod IP 地 
址 实际 存在 于 某 个 网 卡 (可 以 是 虚拟 设备 ) 上 ， 而 Service 的 地 址 却 是 
一 个 虚拟 耳 地 址 ， 没 有 任何 网 络 接口 配置 此 地 址 ， 它 由 kube-proxy 借 助 
iptables 规 则 或 ipvs 规 则 重新 定 回 到 本 地 端口 ， 再 将 其 调度 至 后 端 Pod 对 
象 。Service 的 了 地址 是 集群 提供 服务 的 接口 ， 也 称 为 Cluster IP 。 


Pod 网 络 及 其 IP 由 Kubernetes 的 网 络 插件 负责 配置 和 管理 ， 具 体 使 
用 的 网 络 地 址 可 在 管理 配置 网 络 插件 时 指定 ， 如 10.244.0.0/16 网 络 。 而 
Cluster 网 络 和 IP 则 是 由 Kubernetes 集 群 负 责 配 置 和 管理 ， 如 10.96.0.0/12 
网 络 。 


总 结 起 来 ，Kubernetes 集 群 至 少 应 该 包含 三 个 网 络 ， 如 图 1-13 中 的 
网 络 环境 所 示 。 一 个 是 各 主机 (Master、Node 和 etcd 等 ) 自身 所 属 的 网 
络 ， 其 地 址 配置 于 主机 的 网 络 接口 ， 用 于 各 主机 之 间 的 通信 ， 例 如 ， 
Master 与 各 Node 之 间 的 通信 。 此 地 址 配置 于 Kubernetes 集 群 构建 之 前 ， 
它 并 不 能 由 Kubernetes 管 理 ， 管 理 员 需要 于 集群 构建 之 前 自行 确定 其 地 
址 配置 及 管理 方式 。 第 二 个 是 Kubernetes 集 群 上 专用 于 Pod 资 源 对 象 的 


网 络 ， 它 是 一 个 虚拟 网 络 ， 用 于 为 各 Pod 对 和 象 设 定 IP 地 址 等 网 络 参数 ， 
0 中 容器 的 网 络 接 口 之 上 。Pod 网 络 需 要 借助 kubenet 插 
件 或 CNI 插 件 实现 ， 该 插件 可 独立 部 署 于 Kubernetes 集 群 之 外 ， 亦 可 托 
管 于 Kubernetes 之 上 ， 它 需要 在 构建 Kubernetes 集 群 时 由 管理 员 进行 定 
义 ， 而 后 在 创建 Pod 对 象 时 由 其 自动 完成 各 网 络 参 数 的 动态 配置 。 

个 是 专用 于 Service 资 源 对 象 的 网 络 ， 它 也 是 一 个 虚拟 网 络 ， 用 于 为 一 
Kubernetes 集 群 之 中 的 Service 配 置 IP 地 址 ， 但 此 地 址 并 不 配置 于 任何 主 
机 或 容器 的 网 络 接口 之 上 ， 而 是 通过 Node 之 上 的 kube- proxy 配置 为 
iptables 或 ipvs 规 则 ， 从 而 将 发 往 此 地 址 的 所 有 流量 调度 至 其 后 端的 各 
Pod 对 和 象 之 上 。Service 网 络 在 Kubernetes 和 集群 创建 时 予以 指定 ， 而 各 
Service 的 地 址 则 在 用 户 创建 Service 时 予以 动态 配置 。 


Service 网 络 


Pod 网 和 


ba kube- 
加 Pod 
ba pIOXY 
Master 一 一 一 一 一 一 一 
Nodel Node2 
方 点 网 络 | 


图 1-13 ”Kubernetes 网 络 环 境 


le 提示 CNI 是 指 容器 网 络 接口 (Container Network 
Interface) ， 是 由 CNCF (Cloud Native Computing Foundation) 维护 的 
项 目 ， 其 由 一 系列 的 用 于 编写 配置 容 需 网 络 插件 的 规范 和 库 接 口 
(libcni) 组 成 ， 支 持 众多 插件 项 目 。 后 文 对 此 有 详细 说 明 。 


1.4.2 ”集群 上 的 网 络 通信 


Kubernetes 集 群 的 客户 端 大 体 可 以 分 为 两 类 : API Server 客 户 端 和 
应 用 程序 (运行 为 Pod 中 的 容器 ) 客户 端 ， 如 图 1-14 所 示 。 第 一 类 客户 
端 通常 包含 人 类 用 户 和 Pod 对 象 两 种 ， 它 们 通过 API Server 访 问 
Kubernetes 集 群 完成 管理 任务 ， 例 如 ， 管 理 集群 上 的 各 种 资源 对 象 。 人 第 
二 类 客户 端 一 般 也 包含 人 类 用 户 和 Pod 对 象 两 种 ， 它 们 的 访问 目标 是 
Pod 上 运行 于 容器 中 的 应 用 程序 提供 的 各 种 具体 的 服务 ， 如 redis 或 nginx 
等 ， 不 过 ， 这 些 访 问 请 求 通常 要 经 由 Service 或 mgress 资 源 对 象 进 行 。 
另外 ， 第 二 类 客户 端的 访问 目标 对 象 的 操作 要 经 由 第 一 类 客户 端 创建 
和 配置 完成 后 才能 进行 。 


开发 / 运 维 应 用 客户 端 
© © 
Par di Soe 


i Server Pod 


~ ~ client \ 
| es | Service 


| Pod 量 十 二 这 | 
| I | | ' Clty 人 


(pod ( Pod ) ( Pod ) ¢ Pod ) 


Kubernetes cluster 


图 1-14 ”Kubernetes 客 户 端 及 其 类 型 


访问 API Server 时 ， 人 类 用 户 一 般 借助 于 命令 行 工 具 kubect 或 网 形 
UI (例如 Kubernetes Dashboard) 进行 ， 也 可 通过 编程 接口 进行 访问 ， 
包括 REST API。 访 问 Pod 中 的 应 用 时 ， 其 访问 方式 要 取决 于 Pod 中 的 应 
例如 ， 对 于 运行 Nginx 容 器 的 Pod 来 说 ， 其 最 常用 工具 自然 是 
浏 蜗 絮 。 


管理 员 〈 开 发 人 员 或 运 维 人 员 ) 使 用 Kubernetes 和 集群 的 常见 操作 包 
括 通过 控制 器 创建 Pod， 在 Pod 的 基础 上 创建 Service 供 第 二 类 客户 端 访 


问 ， 更 新 Pod 中 的 应 用 版 本 (更 新 和 回 深 ) 以 及 对 应 用 规模 进行 扩容 或 
缩 容 等 ， 另 外 还 有 集群 附件 管理 、 存 储 卷 管理 、 网 络 及 网 络 策略 管 

理 、 次 源 管 理 和 安全 管理 等 ， 这 些 内 容 将 在 后 面 的 章节 中 展开 。 不 
过 ， 这 一 切 的 前 提 是 要 先 构建 出 一 个 可 用 的 Kubernetes 集 群 ， 这 一 内 容 
将 在 第 2 章 中 着 重 讲述 。 


1.5 ”本章 小 结 


本 章 介 绍 了 Kubernetes 的 历史 、 功 用 、 特 性 及 其 相关 的 核心 概述 
和 术语 ， 并 简单 描述 了 其 染 构 及 其 各 关键 组 件 ， 以 及 集群 网 络 中 的 常 
见 通信 方式 ， 具 体 如 下 。 


Kubernetes 集 群 主要 由 Master 和 Node 两 类 节点 组 成 。 


.Master 主 要 包含 API Server、controller-manager、Scheduler 和 etcd 
几 个 组 件 ， 其 中 API Server 是 整个 集群 的 网 关 。 


Node 主要 由 kubelet、kube-proxy 和 容 絮 引擎 等 组 件 构成 ，kubelet 
是 Kubernetes 集 群 的 工作 于 节点 之 上 的 代理 组 件 。 


-完整 的 Kubernetes 集 群 还 需要 部 署 有 CoreDNS (或 KubeDNS) 
Prometheus (或 HeapSter) 、Dashboard 和 Ingress Controller 儿 个 附加 组 
件 。 


:Kubernetes 的 网 络 中 主要 存在 四 种 类 型 的 通信 : 同一 Pod 内 的 容 履 
间 通 信 、 各 Pod 间 的 通信 、Pod 与 Service 间 的 通信 ， 以 及 集群 外 部 的 流 
量 同 Service 之 间 的 通信 。 


第 2 章 Kubernetes 快 速 入 门 


Kubernetes 集 群 将 所 有 下 点 上 的 资源 都 整合 到 一 个 大 的 虚拟 资源 
池 里 ， 以 代替 一 个 个 单独 的 服务 右 ， 而 后 开放 诸如 CPU、 内 存 和 IO 这 
些 基本 资源 用 于 运行 其 基本 单元 一 Pod 资 源 对 象 。Pod 的 容器 中 运行 着 
隔离 的 任务 单元 ， 它 们 以 Pod 为 原子 单位 ， 并 根据 其 资源 需求 从 虚拟 
资源 池 中 为 其 动态 分 配 资源 。 知 可 以 将 整个 集群 类 比 为 一 台 传 统 的 服 
务 器 ， 那 么 Kubernetes (Master) 就 好 比 是 操作 系统 内 核 ， 其 主要 职责 
在 于 抽象 资源 并 调度 任务 ， 而 Pod 资 源 对 象 就 是 那些 运行 于 用 户 空间 
中 的 进程 。 于 是 ， 传 统 意义 上 的 同音 市 点 或 集群 直接 部 署 、 配 置 应 用 
的 0 渐 式 徽 ， 取 而 代 之 的 是 同 Kubernetes 的 API Server 提 交 运 行 
Pod 六 9 


API Server 是 人 负责 接收 并 啊 应 客户 端 提 交 任 务 的 接口 ， 用 户 可 使 用 
诸如 CLI 工 具 (如 kubectl) 、UI 工 具 (如 Dashboard) 或 程序 代码 ( 客 
户 端 开发 库 ) 发 起 请 求 ， 其 中 ，kubectl 是 最 为 常用 的 交互 式 命令 行 工 
具 。 快 速 了 解 Kubemetes 的 办 法 之 一 就 是 部 署 一 个 测试 集群 ， 并 演 试 
测试 使 用 它 的 各 项 基本 功能 。 本 章 在 简单 介绍 核心 资源 对 象 后 将 尝试 
使 用 kubectl 创 建 Deployment 和 Service 资 源 部 署 并 又 露 一 个 Web 应 用 ， 

以 便 读者 快速 了 解 如 何在 Kubernetes 系 统 上 运行 应 用 程序 的 核心 任 


7 


2.1 Kubernetes 的 核心 对 象 


API Server 提 供 了 RESTful 风 格 的 编程 接口 ， 其 管理 的 资源 是 
Kubernetes API 中 的 端点 ， 用 于 存储 某 种 API 对 象 的 集合 ， 例 如 ， 内 置 
Pod 资 源 是 包含 了 所 有 Pod 对 象 的 集合 。 资 源 对 象 是 用 于 表现 集群 状态 
的 实体 ， 常 用 于 摘 述 应 于 哪个 节点 进行 容 絮 化 应 用 、 需 要 为 其 配置 什 
么 资源 以 及 应 用 程序 的 管理 策略 等 ， 例 如 ， 重 局、 升级 及 容错 机 制 。 
另外 ， 一 个 对 象 也 是 一 种 “ 意 回 记录 "一 一 旦 创建 ，Kubernetes 束 需要 一 
人 。Pod、Deployment 和 和 Service 等 都 是 最 常用 的 核心 
对 象 。 


2.1.1 Pod 资 源 对 象 


Pod 资 源 对 象 是 一 种 集合 了 一 到 多 个 应 用 容器 、 存 储 贸 2 专用 IP 
及 支撑 容器 运行 的 其 他 选项 的 逻辑 组 件 如 图 2- 有 。 换言之 ，Pod 
代表 着 Kubernetes 的 部 署 单 元 及 原子 运行 单元 ， 即 一 个 应 / 用 柚 译 | 
| 它 通常 由 共 吾 资源 且 关 系 紧 密 的 一 个 或 多 个 应 用 容 嚼 


Pod 


a Contail 村 
时 
En Tocalhost | / 
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Pause rs 


、 _ | eth0 | |volume| 


Pod IP 10.244.1.6 
图 2-1 ”Pod 通 党 由 一 到 多 个 共 邓 网 络 和 存储 资源 的 容器 组 合 而 成 


Kubernetes 的 网 络 模型 要 求 其 各 Pod 对 象 的 也 地址 位 于 同一 网 络 平 
面 内 〈 同 一 了 网 段 ) ， 各 Pod 之 间 可 使 用 其 了 地 址 直接 进行 通信 ， 无 论 
它们 运行 于 集群 内 的 哪个 工作 节点 之 上 ， 这 些 Pod 对 象 都 像 是 运行 于 
同一 局 域 网 中 的 多 个 主机 。 


读者 可 以 将 每 个 Pod 对 象 想象 成 一 个 逻辑 主机 ， 它 类 似 于 现实 世 

界 中 的 物理 主机 或 YM (Virtual Machine) ， 运 行 于 同一 个 Pod 对 象 中 

的 多 个 进程 也 类 似 于 物理 机 或 VM 上 独立 运行 的 进程 。 不 过 ，Pod 对 象 

中 的 各 进程 均 运 行 于 彼此 隔离 遇 容 髓 中 ， 并 于 各 容器 间 共 享 两 种 关键 
资源 : 网 络 和 存储 卷 。 


.网 络 networking) : 每 个 Pod 对 象 都 会 被 分 配 一 个 集群 内 专用 的 
IP 地 址 ， 也 称 为 Pod IP， 同 一 Pod 内 部 的 所 有 容器 共 部 Pod 对 象 的 
Network 和 UTS 名 称 空间 ， 其 中 包括 主机 名 、 卫 地 址 和 端口 等 。 因 此 ， 


这 些 容 器 间 的 通信 可 以 基于 本 地 回环 接口 lo 进行 ， 而 与 Pod 外 的 其 他 组 
通信 则 需要 使 用 Service 资 源 对 象 的 ClusterIP 及 其 相应 的 端口 完 


.存储 卷 (volume) : 用 户 可 以 为 Pod 对 和 象 配置 一 组 “存储 卷 ? 资 
源 ， 这 些 资 源 可 以 共享 给 其 内 部 的 所 有 容器 使 用 ， 从 而 完成 容器 间 数 
据 的 共享 。 存 储 卷 还 可 以 确保 在 容器 终止 后 被 重 局 ， 其 至 是 被 删除 后 
ns 丢失 ， 从 而 保证 了 生命 周期 内 的 Pod 对 象 数 据 的 持 

子 化 o 


一 个 Pod 对 象 代表 某 个 应 用 程序 的 一 个 特定 实例 ， 如 果 需 要 扩展 
应 用 程序 ， 则 意味 着 为 此 应 用 程序 同时 创建 多 个 Pod 实 例 ， 每 个 实例 
均 代表 应 用 程序 的 一 个 运行 的 “副本 ” (replica) 。 这 些 副 本 化 的 Pod 对 
象 的 创建 和 管理 通常 由 另 一 组 称 之 为 “控制 器 ”(Controller) 的 对 象 实 
现 ， 例 如 ，Deployment 控 制 器 对 象 。 


创建 Pod 时 ， 还 可 以 使 用 Pod Preset 对 象 为 Pod 注 入 特定 的 信息 ， 如 
ConfigMap、Secret、 存 储 卷 、 卷 挂 载 和 环境 变量 等 。 有 了 Pod Preset 对 
象 ，Pod 模 板 的 创建 者 就 无 须 为 每 个 模板 显 式 提 供 所 有 信息 ， 因 此 ， 
也 就 无 须 事 和 完了 解 需 要 配置 的 每 个 应 用 的 细 广 即 可 完成 模板 定义 。 这 
些 内 容 将 在 后 面 的 章节 中 予以 介绍 。 


基于 期 望 的 目标 状态 和 各 节点 的 资源 可 用 性 ，Master 会 将 Pod 对 象 
调度 至 某 选 定 的 工作 节点 运行 ， 工 作 节 点 于 指向 的 镜像 仓库 (image 
registry) 下 载 镜像 ， 并 于 本 地 的 容器 运行 时 环境 中 启动 容器 。Master 
会 将 整个 集群 的 状态 保存 于 etcd 中 ， 并 通过 API Server 共 享 给 集群 的 各 
组 件 及 客户 端 。 


2.1.2 Controller 


Kubernetes 集 群 的 设计 中 ，Pod 是 有 生命 周期 的 对 象 。 用 户 通 过 手 
工 创建 或 由 Controller (控制 絮 ) 直接 创建 的 Pod 对 象 会 被 “调度 
絮 ” (Scheduler) 调度 至 集群 中 的 某 工作 节点 运行 ， 待 到 容 需 应 用 进程 
运行 结束 之 后 正常 终止 ， 随 后 融会 被 删除 。 另 外 ， 克 点 资源 耗 尽 或 故 
障 也 会 导致 Pod 对 象 被 回收 。 


但 Pod 对 象 本 喘 并 不 具有 “上 自 钝 ”功能 ， 若 是 因为 工作 节点 甚至 是 调 
度 需 目 喘 导致 了 运行 失败 ， 那 么 它 将 会 被 删除 ， 同 样 ， 资 源 耗 尽 或 节 
点 故障 导致 的 回收 操作 也 会 删除 相关 的 Pod 对 象 。 在 设计 上 ， 
Kubernetes 使 用 “控制 器 ”实现 对 一 次 性 的 (用 后 即 充 ) Pod 对 象 的 管理 
操作 ， 例 如 ， 要 确保 部 署 的 应 用 程序 的 Pod 副 本 数量 严格 反映 用 户 期 
望 的 数目 ， 以 及 基于 Pod 模 板 来 重建 Pod 对 象 等 ， 从 而 实现 Pod 对 象 的 
扩 缩 容 、 滚 动 更 新 和 上 自 愈 能 力 等 。 例 如 ， 某 节点 发 生 故 障 时 ， 相 关 的 
控制 器 会 将 此 市 点 上 运行 的 Pod 对 象 重新 调度 到 其 他 方 点 进行 重建 。 


控制 器 本 身 也 是 一 种 资源 类 型 ， 它 有 着 多 种 实现 ， 其 中 与 工作 负 
载 相关 的 实现 如 Replication Controller、Deployment 、StatefulSet 、 
DaemonSet、DaemonSet 和 Jobs 等 ， 也 可 统称 它们 为 Pod 控 制 咽 。 如 图 2- 
2 中 的 Deployment 束 是 这 类 控制 器 的 代表 实现 ， 是 目前 最 常用 的 管理 无 
状态 应 用 的 Pod 控 制 器 。 


Pod 控 制 器 的 定义 通常 由 期 望 的 副本 数量 、Pod 模 板 和 标签 选择 器 
(Label Selector) 组 成 。Pod 控 制 器 会 根据 标签 选择 器 对 Pod 对 象 的 标 
签 进行 匹配 检查 ， 所 有 满足 选择 条 件 的 Pod 对 象 都 将 受 控 于 当前 控制 
器 并 计 入 其 副本 总 数 ， 并 确保 此 数目 能 够 精确 反映 期 望 的 副本 数 。 


需要 注意 的 是 ， 在 实际 的 应 用 场景 中 ， 在 接收 到 的 请 求 流量 负载 
显著 低 于 或 接近 于 已 有 Pod 副 本 的 整体 承载 能 力 时 ， 用 户 需 要 手动 修 
改 Pod 控 制 絮 中 的 期 望 副 本 数量 以 实现 应 用 规模 的 扩容 或 缩 容 。 不 
过 ， 若 集群 中 部 署 了 HeapSter 或 Prometheus 一 类 的 资源 指标 监控 附件 
时 ， 用 户 还 可 以 使 用 “HorizontalPodAutoscaler” (HPA) 计算 出 合适 的 
Pod 副 本 数量 ， 并 上 自动 修改 Pod 控 制 絮 中 期 望 的 副本 数 以 实现 应 用 规模 
的 动态 伸缩 ， 提 高 集群 资源 利用 率 ， 如 图 2-3 所 示 。 


Kubernetes 集 群 中 的 每 个 广 扩 部 运行 者 cAdvisor 以 收集 容器 及 下 点 
的 CPU、 内 存 及 偿 熏 资源 的 利用 率 指标 数据 ， 这 些 统计 数据 eonste 
聚合 后 可 通过 API Server 访 问 。 II i 文 些 统计 


数据 监控 容 右 健康 状态 并 做 出 扩展 决策 。 
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图 2-2 Replication Controller 
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图 2-3 Horizontal Pod Autoscaler 


2.1.3 Service 


尽管 Pod 对 象 可 以 拥有 IP 地 址 ， 但 此 地 址 无 法 确保 在 Pod 对 象 重启 
或 个 重建 后 保持 不 变 ， 这 会 为 集群 中 的 Pod 应 用 间 依 赖 关 系 的 维护 带 
来 麻烦 : 前 端 Pod 应 用 (依赖 方 ， 无 法 基于 固定 地 址 持续 跟踪 后 端 Pod 
应 用 〈 被 依赖 方 ) 。 于 是 ，Service 资 源 被 用 于 在 被 访问 的 Pod 对 象 中 
添加 一 个 有 着 固定 了 地址 的 中 间 层 ， 客 户 端 回 此 地 址 发 起 访问 请 求 后 
由 相关 的 Service 资 源 调度 并 代理 至 后 端的 Pod 对 象 。 


换言之 ，Service 是 “微服 务 ” 的 一 种 实现 ， 事 实 上 它 是 一 种 抽象 : 
通过 规则 定义 出 由 多 个 Pod 对 象 组 合 而 成 的 逻辑 集合 ， 并 附 市 访问 这 
组 Pod 对 和 象 的 策略 。Service 对 象 挑 选 、 关 联 Pod 对 和 象 的 方式 同 Pod 控 制 
器 一 样 ， 都 是 要 基于 Label Selector 进 行 定 义 ， 其 示意 图 如 图 2-4 所 示 。 
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图 2-4 Service 对 象 功能 示意 


Service IP 是 一 种 虚拟 也 ， 也 称 为 Cluster IP， 它 专用 于 集群 内 通 
信 ， 通 常 使 用 专用 的 地 址 段 ， 如 “10.96.0.0/12” 网 络 ， 各 Service 对 象 的 
IP 地 址 在 此 范围 内 由 系统 动态 分 配 。 


集群 内 的 Pod 对 象 可 直接 请 求 此 类 的 Cluster IP， 例 如 ， 图 2-4 中 来 
自 pod client 的 访问 请 求 即 可 以 Service 的 Cluster IP 作 为 目标 地 址 ， 但 集 
群 网 络 属于 私有 网 络 地 址 ， 它 们 仅 在 集群 内 部 可 达 。 将 集群 外 部 的 访 
问 流 量 引 入 集群 内 部 的 常用 方法 是 通过 节点 网 络 进 行 ， 实 现 方 法 是 通 
过 工作 节点 的 IP 地 址 和 某 端口 (NodePort) 接 入 请 求 并 将 其 代理 至 相 
应 的 Service 对 象 的 Cluster IP 上 的 服务 端口 ， 而 后 由 Service 对 和 象 将 请 求 
代理 至 后 端的 Pod 对 象 的 Pod IP 及 应 用 程序 监听 的 端口 。 因 此 ， 诸 如 图 
2-4 中 的 External Clients 这 种 来 目 集群 外 部 的 客户 端 无 法 直接 请 求 此 
Service 提 供 的 服务 ， 而 是 需要 事先 经 由 某 一 个 工作 节点 (如 Node YY) 
的 IP 地 址 进行 ， 这 类 请 求 需要 两 次 转发 才能 到 达 日 标 Pod 对 象 ， 因 此 在 
通信 效率 上 必然 存在 负面 影响 。 


事实 上 ，NodePort 会 部 署 于 集群 中 的 每 一 个 下 点 ， 这 了 驶 意味 着 ， 
集群 外 部 的 客户 端 通过 任何 一 个 工作 和 点 的 卫 地 址 来 访问 定义 好 的 
NodePort 都 可 以 到 达 相 应 的 Service 对 象 。 此 种 场景 中 ， 如 果 存 在 集群 
外 部 的 一 个 负载 均衡 絮 ， 即 可 将 用 户 请 求 负载 均衡 至 集群 中 的 部 分 或 
者 所 有 节点 。 这 是 一 种 称 为 "LoadBalancer” 类 型 的 Service， 它 通 销 是 由 
Cloud Provider 目 动 创 建 并 提供 的 软件 负载 均衡 右 ， 不 过 ， 也 可 以 是 由 
管理 员 手 工 配置 的 诸如 F5Big-IP 一 类 的 人 硬件 设备 。 


简单 来 说 ，Service 主 要 有 三 种 常用 类 型 . 第 一 种 是 仅 用 于 集群 内 
部 通信 的 ClusterIP 类 型 ， 第 二 种 是 接 入 集群 外 部 请 求 的 NodePort 类 
型 ， 它 工作 于 每 个 市 点 的 主机 IP 之 上 ; 第 三 种 是 LoadBalancer 类 型 ， 它 
可 以 把 外 部 请 求 负 和 载 均衡 至 多 个 Node 的 主机 IP 的 NodePort 之 上 。 此 三 
种 类 型 中 ， 每 一 种 都 以 其 前 一 种 为 基础 才能 实现 ， 而 且 第 三 种 类 型 中 
的 LoadBalancer 需 要 协同 集群 外 部 的 组 件 才能 实现 ， 并 且 此 外 部 组 件 
并 不 接受 Kubernetes 的 管理 。 


2.1.4 部 署 应 用 程序 的 主体 过 程 


Docker 容 器 技术 使 得 部 署 应 用 程序 从 传统 的 安装 、 配 置 、 局 动 应 
用 程序 的 方式 转 为 于 容器 引擎 上 基于 镜像 创建 和 运行 容器 ， 而 
Kubernetes 义 使 得 创建 和 运行 容器 的 操作 不 必 再 关注 其 位 置 ， 并 在 一 定 
程度 上 赋予 了 它 动 态 扩 缩 容 及 目 愈 的 能 力 ， 从 而 让 用 户 从 主机 、 系 统 
及 应 用 程序 的 维护 工作 中 解脱 出 来 。 


用 到 某 应 用 程序 时 ， 用 户 只 需要 癌 API Server 请 求 创建 一 个 Pod 控 
制 器 ， 由 控制 器 根据 镜像 等 信息 同 API Server 请 求 创建 出 一 定数 量 的 
Pod 对 象 ， 并 由 Master 之 上 的 调度 器 指派 至 选 定 的 工作 节点 以 运行 容器 
化 应 用 。 此 外 ， 用 户 一 般 还 需要 创建 一 个 具体 的 Service 对 象 以 便 为 这 
些 Pod 对 象 建立 起 一 个 固定 的 访问 入 口 ， 从 而 使 得 其 客户 端 能 够 通过 其 
服务 名 称 或 ClusterIP 进 行 访问 ， 如 图 2-5 所 示 。 
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图 2-5 ”应 用 程序 简单 的 部 署 示例 


API Server 的 常用 客户 端 程序 是 Kubernetes 系 统 自 这 的 命令 行 工具 
kubectl， 它 通过 一 众 子 命令 用 于 实现 集群 及 相关 资源 对 象 的 管理 操 
作 ， 并 支持 直接 命令 式 、 命 令 式 配置 清单 及 声明 式 配置 清单 等 三 种 操 
作 方 式 ， 特 性 丰富 日 功 能 强大 。 而 需 作为 集群 附件 额外 部 署 的 
Dashboard 则 提供 了 基于 Web 界 面 的 图 形 客 户 端 ， 它 是 一 个 通用 目的 管 
理工 具 ， 与 Kubernetes 紧 密集 成 ， 支 持 多 级 别 用 户 授权 ， 能 在 一 定 程度 
上 替代 kubect 的 大 多 数 操 作 。 


本 章 后 面 的 篇 幅 将 介绍 在 部 署 完成 的 Kubernetes 集 群 环境 中 如 何 快 
速 部 署 如 图 2-5 所 示 的 示例 应 用 程序 ， 并 简单 说 明 如 何 完成 对 容器 化 应 
用 的 访问 ， 以 及 如 何 进行 应 用 规模 的 动态 伸缩 ， 并 借 此 让 读者 了 解 
kubectl 命 令 的 基本 功能 和 用 法 。 


2.2 部署 Kubernetes 集 群 


Kubemetes 系 统 可 运行 于 多 种 平台 之 上 上， 包括 虚 拟 机 、 裸 服务 器 
或 PC 等 ， 例 如 本 地 主机 或 托管 的 云端 虚拟 机 。 若 仅 用 于 快速 了 解 或 开 
发 的 目的 ， 那 么 读者 可 直接 于 单个 主机 之 上 部 署 “ 伪 ” 分 布 式 的 
Kubernetes 集 群 ， 将 集群 的 所 有 组 件 均 部 署 运行 于 单 台 主机 上 ， 著 名 
的 minukube 项 目 可 帮助 用 户 快 速 构建 此 类 环境 。 如 果 要 学 习 使 用 
Kubernetes 集 群 的 完整 功能 ， 则 应 该 构建 真正 的 分 布 式 集群 环境 ， 将 
Master 和 Node 等 部 署 于 多 台 主 机 之 上 ， 主 机 的 具体 数量 要 按 实际 需求 
而 定 。 男 外 ， 集 群 部 署 的 方式 也 有 多 种 选择 ， 人 简单 的 可 以 基于 
kubeadm 一 类 的 部 署 工 具 运 行 儿 条 命令 即 可 实现 ， 而 复杂 的 则 可 以 是 
从 零 开 始 手动 构建 集群 环境 。 


2.2.1 kubeadm 部 署 工 具 


kubeadm 是 Kubernetes 项 目 自 沉 的 集群 构建 工具 ， 它 负责 执行 构建 
一 个 最 小 化 的 可 用 集群 以 及 将 其 局 动 等 的 必要 基本 步 又， 人 简单 来 讲 ， 
kubeadm 和 是 Kubernetes 集 群 全 生命 周期 的 管理 工具 ， 可 用 于 实现 集群 的 
部 署 、 升 级 /降级 及 拆除 ， 如 图 2-6 所 示 。 不 过 ， 在 部 署 操作 中 ， 
kubeadm 仅 关心 如 何 初 始 化 并 启动 集群 ， 余 下 的 其 他 操作 ， 例 如 安 闭 
Kubernetes Dashboard、 监 探 系 统 、 日 志 系 统 等 必要 的 附加 组 件 则 不 在 
其 考虑 范围 之 内 ， 需 要 管理 员 按 需 上 自行 部 署 。 
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图 2-6 ”kubeadm 功 能 示意 图 


kubeadm 集 成 了 kubeadm init 和 kubeadm join 等 工具 程序 ， 其 中 
kubeadm init 用 于 集群 的 快速 初始 化 ， 其 核 心切 能 是 部 署 Master 记 反 的 
各 个 组 件 ， 而 kubeadm join 则 用 于 将 世上 点 快速 加 入 到 指定 集群 中 ， 它 们 
是 创建 Kubernetes 集 群 最 佳 实践 的 “快速 路 径 ”。 另 外 ，kubeadm token 可 
于 集群 构建 后 管理 用 于 加 入 集群 时 使 用 的 认证 令 牌 (token) ， 而 
I reset 命 令 的 功能 则 是 删除 集群 构建 过 程 中 生成 的 文件 以 重 置 回 
人 口 1 人 TGS ” 


kubeadm 还 支持 管理 初始 引导 认证 令 牌 (Bootstrap Token) ， 完 成 
待 加 入 的 新 节点 首次 联系 API Server 时 的 身份 认证 (基于 共享 密 钥 ) 。 
另外 ,它们 还 文 持 管理 集群 版 本 的 升级 和 降级 操作 。Kubernetes 1.8 版 


本 之 前 ，kubeadm 一 直 处 于 beta 级 别 ， 并 警告 不 能 用 于 生产 环境 。 不 
过 ， 自 1.9 版 本 开始 ， 其 虽 仍 处 于 beta 版 本 ， 但 已 经 不 再 输出 警告 信 

妃 ， 而 随 着 1.11 版 本 发 布 的 kubeadm 又 得 到 了 进一步 的 增强 ， 它 文 持 动 
态 配 置 kubelet， 通 过 增强 的 CRI 集 成 文 持 动 态 探测 以 判定 所 用 的 容 侦 引 
擎 ， 并 引入 了 几 个 新 的 命令 行 工 具 ， 包 括 kubeadm config print-default、 
kubeadm config migrate ~ kubeadm config images pul 和 kubeadm upgrade 
node config 等 。 总 体 来 说 ， 使 用 kubeadm 部 署 Kubernetes 集 群 具 有 如 下 
儿 个 方面 的 优势 。 


-简单 易 用 :kubeadm 可 完成 集群 的 部 署 、 升 级 和 拆除 操作 ， 并 且 
对 新 手 用 户 非 常 友好 。 


.适用 领域 广泛 : 支持 将 集群 部 署 于 裸 机 、VMware、AWS、 
Azure、GCE 及 更 多 环境 的 主机 上 ， 且 部 署 过 程 基本 一 致 。 


富有 弹性 ，1.11 版 中 的 kubeadm 文 持 阶 段 式 部 署 ， 管 理 员 可 分 为 多 
个 独立 步 又 完成 部 署 操作 。 


.生产 环境 可 用 : kubeadm 遵 循 以 最 佳 实践 的 方式 部 署 Kubernetes 集 
群 ， 它 强制 启用 RBAC， 设 定 Master 的 各 组 件 间 以 及 API Server 与 kublet 
之 间 进 行 认 证 及 安全 通信 ， 并 锁定 了 kubelet API 等 。 


由 此 可 见 ，kubeadm 并 非 一 键 安装 类 的 解决 方案 ， 相 反 ， 它 有 着 更 
宏大 的 目标 ， 间 在 成 为 一 个 更 大 解决 方案 的 一 部 分 ， 试 图 为 集群 创建 
和 运营 构建 一 个 声明 式 的 API 驱 动 模型 ， 它 将 集群 本 身 视 为 不 可 变 组 
件 ， 而 升级 操作 等 同 于 全 新 部 署 或 就 地 更 新 。 目 前 ， 使 用 kubeadm 部 署 
集群 已 经 成 为 越 来 越 多 的 Kubernetes 工 程 师 的 选择 。 


2.2.2 ”集群 运行 模式 


Kubernetes 集 群 支 持 三 种 运行 模式 : 一 是 “独立 组 件 ?模式 ， 系 统 各 
组 件 直 接 以 守护 进程 的 方式 运行 于 和 点 之 上 ， 各 组 件 之 间 相 互 协作 构 
成 集群 ， 如 图 2-7b 所 示 ; 第 二 种 是 “静态 Pod 模 式 ”"， 除 kubelet 和 Docker 
之 外 的 其 他 组 件 《如 etcd、kube-apiserver、kube-controller-manager 和 
kube-scheduler 等 ) 都 是 以 静态 Pod 对 象 运 行 于 Master 主 机 之 上 的 ， 如 图 
2-7a 所 示 ; 第 三 种 是 Kubernetes 的 “ 自 托 管 ”(self-hosted) 模式 ， 它 类 似 
于 第 二 种 方式 ， 将 除了 kubelet 和 Docker 之 外 的 其 他 组 件 运 行为 集群 之 
上 的 Pod 对 象 ， 但 不 同 的 是 ， 这 些 Pod 对 象 托 管 运行 在 集群 自身 之 上 受 
控 于 DaemonSet 类 型 的 控制 妖 ， 而 非 静 态 的 Pod 对 象 。 


Kubernetes cluster Kubernetes cluster 
\| Pod Pod 
master 
proxy node master node 
etcd Do 
scheduler 
api- etcd 
server 
scheduler 
Controller- 
proxy 
manager controller-manager 
| kubelet docker kubelet docker SP SEV kubelet | | docker 
a) b) 


图 2-7 ”Kubernetes 集 群 的 运行 模式 (图 2-7a 为 静态 Pod 模 式 ) 


使 用 kubeadm 部 署 的 Kubernetes 集 群 可 运行 为 第 二 种 或 第 三 种 模 
式 ， 默 认为 静态 Pod 对 象 模式 ， 需 要 使 用 目 托管 模式 时 ，kubeadm init 命 
令 使 用 “--features-gates=selfHosting” 选 项 即 可 。 第 一 种 模式 集群 的 构建 
需要 将 各 组 件 运行 于 系统 之 上 的 独立 守护 进程 中 ， 其 间 需 要 用 到 的 证 
书 及 Token 等 认证 信息 也 都 需要 手动 生成 ， 过 程 烦 琐 有 旦 极 易 出 错 ， 若 有 


必要 用 到 ， 则 建议 使 用 GitHub 上 合用 的 项 目 辅助 进行 ， 例 如 ， 通 过 
ansible playbook 进 行 自动 部 署 等 。 


2.2.3 ”准备 用 于 实践 操作 的 集群 环境 


本 书后 面 的 篇 幅 中 用 到 的 测试 集群 如 图 2-8 所 示 ， 该 集群 由 一 个 
Master 主 机 和 三 个 Node 主 机 组 成 ， 它 基于 kubeadm 部 署 ， 除 了 kubelet 和 
Docker 之 外 其 他 的 集群 组 件 都 运行 于 Pod 对 象 中 。 多 数 情 况 下 ， 两 个 或 
以 上 的 独立 运行 的 Node 主 机 即 可 测试 分 布 式 集群 的 核心 功能 ， 因 此 其 
数量 可 按 需 定义 ， 但 两 个 主机 是 模拟 分 布 式 环境 的 最 低 需 求 。 和 生产 实 
践 中 ， 应 该 至 少 部 署 三 个 协同 工作 的 Master 万 点 以 确保 控制 平面 的 服务 
可 用 性 ， 不 过 ， 在 测试 环境 中 仅 部 署 一 个 Master 世 点 也 是 利 见 的 选择 。 


Service 网 络 : 10.96.0.0/12 


master | . 
etcd Pod | | kube-proxy Pod node01 node02 node03 
kube-controller-manager Pod kube-proxy Pod | ( kube-proxy Pod 图 kube-proxy Pod | 
kube-scheduler Pod | 
docker | 


kube-apiserver Pod kubelet 
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Ce Ca Ey 
flannel Pod flannel Pod ] | flannel Pod [ flannel Pod | 
| | | | 


一 


| 


I 
节点 网 络 : 172.16.0.0/16 


Pod 网 络 : 10.244.0.0/16 


图 2-8 Kubernetes 集 群 部 署 目标 示意 图 


各 Node 上 采用 的 容器 运行 时 环境 为 docker， 后 续 的 众多 容器 的 运 
行 任 务 都 将 依赖 于 Docker Registry 服 务 ， 包 括 DockerHub、GCR 
(Google Container Registry) 和 Quay 等 ， 甚 至 是 私有 的 Registry 服 务 ， 
本 书 假设 读者 对 Docker 容 器 技术 有 熟练 的 使 用 基础 。 男 外 ， 本 部 署 示 
例 中 使 用 的 用 于 为 Pod 对 和 象 提 供 网 络 功 能 的 插件 是 flannel， 其 同样 以 
Pod 对 象 的 形式 托管 运行 于 Kubernetes 系 统 之 上 。 


具体 的 部 署 过 程 以 及 本 书 用 到 的 集群 环境 请 参考 附录 A， 本 章 后 续 
的 操作 都 将 依赖 于 根据 其 步骤 部 署 完成 的 集群 环境 ， 读 者 需要 根据 其 
内 容 成 功 搭建 出 Kubermetes 测 试 集群 后 才能 进行 后 面 章节 的 学 习 。 


2.2.4 获取 集群 环境 相关 的 信息 


Kubermnetes 系 统 目 前 仍 处 于 快速 迭代 阶段 ， 版 本 演进 频繁 ， 读 考 
所 部 署 的 版 本 与 本 书 中 使 用 的 版 本 或 将 有 所 不 同 ， 其 功能 特性 也 将 存 
在 一 定 程度 的 变动 。 因此 ， 事 先 查 看 系统 版 本 ， 以 及 对 比 了 解 不 同 版 
本 则 的 功能 特性 变动 也 将 是 不 可 或 缺 的 步 台 。 当 然 ， 用 户 也 可 选择 安 
装 与 本 书 相 同 的 系统 版 本 。 下 面 的 命令 显示 的 是 当前 使 用 的 客户 端 及 
服务 端 程序 版 本 信息 : 


[root@master ~]# kubect1l version --short=true 
Client Version: v1.12.1 
Server Version: v1.12.1 


名 提示 “Kubernetes 系 统 版 本 变动 时 的 ChangeLog 可 参考 
github.com 站 点 上 相关 版 本 中 的 介绍 。 


Kubernetes 集 群 以 及 部 署 的 附件 CoreDNS 等 提供 了 多 种 不 同 的 服 
务 ， 客 户 端 访问 这 些 服务 时 需要 事先 了 解 其 访问 接口 ， 管 理 员 可 使 
用 “kubectl cluster-info” 命 令 获 取 相 关 的 信息 。 


[root@master ~]# kubectl1 cluster-info 

Kubernetes master is running at https://172.16.0.70:6443 

CoreDNS is running at https://172.16.0.70:6443/api/vi/namespaces/kube-system/ 
services/kube-dns:dns/proxy 


一 个 功能 完整 的 Kubernetes 集 群 应 当 具 备 的 附加 组 件 还 包括 
Dashboard、Ingress Controller 和 Heapster (或 Prometheus) 等 ， 后 续 章 
广 中 的 某 些 概念 将 会 依赖 到 这 些 组 件 ， 读 者 可 选择 在 将 要 用 到 时 再 进 
行 部 署 。 


2.3 ”kubectl 使 用 基础 与 示例 


Kubernetes API 是 管理 其 各 种 资源 对 象 的 唯一 入 口 ， 它 提供 了 一 个 
RESTfu 风 格 的 CRUD (Create、Read、Update 和 Delete) 接口 用 于 查询 
和 修改 集群 状态 ， 并 将 结果 存储 于 集群 状态 存储 系统 etcd 中 。 事 实 
上 ，API server 也 是 用 于 更 新 atcd 中 资源 对 象 状 态 的 唯一 途径 ， 
Kubernetes 的 其 他 所 有 组 件 和 客户 端 都 要 通过 它 来 完成 查询 或 修改 操 
J 图 2-9 所 示 。 从 这 个 角度 来 讲 ， 它 们 都 算得 上 是 API server 的 客 

端 。 


master 


kube-controller-manager | kube-scheduler | 


kubectl + 一 一 一 一 一 kube-apiserver -一 etcd | 


kube-proxy 
四 上 node docker 


图 2-9 API Server 及 其 部 分 客户 端 


任何 RESTfu 风 格 API 中 的 核心 概念 都 是 “资源 ” (resource) ， 它 是 
具有 类 型 、 关 联 数据 、 同 其 他 资源 的 关系 以 及 可 对 其 执行 的 一 组 操作 
方法 的 对 象 ， 它 与 对 象 式 编程 语言 中 的 对 象 实例 类 似 ， 两 者 之 间 的 重 
要 区 别 在 于 RESTful API 仅 为 资源 定义 了 少量 的 标准 方法 (对 应 于 标准 
HTTP 的 GET、POST、PUT 和 DELETE 方 法 ) ， 而 编程 语言 中 的 对 象 
实例 通常 有 很 多 方法 。 另 外 ， 资 源 可 以 根据 其 特性 分 组 ， 每 个 组 是 同 
一 类 型 资源 的 集合 ， 它 仅 包含 一 种 类 型 的 资源 ， 并 且 各 资源 间 不 存在 


顺序 的 概念 ， 集 合 本 身 也 是 资源 。 对 应 于 Kubernetes 中 ，Pod、 
Rs 等 都 是 所 谓 的 资源 类 型 ， 它 们 由 相应 类 型 的 对 和 象 


API Server 通 过 认证 (Authentication) 、 授 权 (Authorization) 和 
准 入 控制 (Admission Control) 等 来 管理 对 资源 的 访问 请 求 ， 因 此 ， 
来 自 了 任何 客户 器 (如 kubectl、kubelet、kube-proxy 等 ) 的 访问 请 求 都 
必须 事先 完成 认证 之 后 方 可 进行 后 面 的 其 他 操作 。API Server 支 持 多 种 
2 客户 端 可 以 使 用 命令 行 选项 或 专用 的 配置 文件 〈 称 为 
人 提供 认证 信息 ,相关 的 内 容 将 在 后 面 的 章节 中 给 予 详细 说 
四 可 二 


kubectl 的 核心 功能 在 于 通过 API Server 操 作 Kubernetes 的 各 种 资源 
对 象 ， 它 支持 三 种 操作 方式 ， 其 中 直接 命令 式 (Tmperative 
commands) 的 使 用 最 为 简便 ， 是 了 解 Kubernetes 集 群 管理 的 一 种 有 效 


途径 。 
kubectl 命 令 稼 用 操作 示例 


为 了 便于 读者 快速 适应 kubect 的 命令 操作 ， 这 里 给 出 儿 个 使 用 示 
例 用 于 说 明 其 基本 使 用 方法 。 


1. 创 建 资 源 对 象 
直接 通过 kubecd 命 令 及 相关 的 选项 创建 资源 对 象 的 方式 即 为 直接 


命令 式 操 作 ， 例 如 下 面 的 命令 分 别 创建 了 名 为 nginx-deploy 的 
Deployment 探 制 屡 资 源 对 象 ， 以 及 名 为 nginx-svc 的 Service 资 源 对 象 : 


$ kubectl run nginx-deploy --image=nginx:1.12 --replicas=2 
$ kubect1 expose deployment/nginx --name=nginx-svc --port=80 


用 户 也 可 以 根据 资源 清单 创建 资源 对 象 ， 即 命令 式 对 象 配 置 文 
件 ， 例 如 ， 假 设 存在 定义 了 Deployment 对 和 象 的 nginx-deploy.yaml 文 件 ， 
和 定义 了 Service 对 象 的 nginx-svc.yaml 文 件 ， 使 用 kubectl create 命 令 即 
可 进行 基于 命令 式 对 象 配 置 文件 的 创建 操作 : 


$ kubect1l create -f nginx-deploy.yaml -f nginx-svc.yaml 


甚至 还 可 以 将 创建 由 kubect 上 自行 确定 ， 用 户 只 需要 声明 期 望 的 
状态 ， 这 种 方式 称 为 声明 式 对 象 配置 。 例 如 ， 假 设 存在 定义 了 
Deployment 对 象 的 nginx-deploy.yaml 文 件 ， 以 及 定义 了 Service 对 象 的 
ee ， 那 么 使 用 kubectl apply 命 令 即 可 实现 声明 式 配 


$ kubectl1 apply -f nginx-deploy.yaml -f nginx-svc.yaml 


本 章 后 面 的 章节 主要 使 用 第 一 种 资源 管理 方式 ， 第 二 种 和 第 三 种 
方式 将 在 后 面 的 章节 中 展开 讲述 。 


2. 查 看 资源 对 象 


运行 着 实际 负载 的 Kubernetes 系 统 上 通常 会 存在 多 种 资源 对 象 ， 
用 户 可 分 类 列 出 感 兴趣 的 资源 对 象 及 其 相关 的 状态 信息 ，“kubectl 
get” 正 是 用 于 完成 此 类 功能 的 命令 。 例 如 ， 列 出 系统 上 所 有 的 
Namespace 资 源 对 象 ， 命 令 如 下 : 


$kubect1 get namespaces 


用 户 也 可 一 次 查看 多 个 资源 类 别 下 的 资源 对 象 ， 例 如 ， 列 出 默认 
名 称 空间 内 的 所 有 Pod 和 Service 对 象 ， 并 输出 额外 信息 ， 可 以 使 用 如 
下 形式 的 kubectl get 命 令 : 


$kubectl1 get pods, services-o wide 


Kubernetes 系 统 的 大 部 分 资源 都 隶属 于 某 个 Namespace 对 象 ， 缺 省 
的 名 称 空间 为 default， 若 需要 获取 指定 Namespace 对 象 中 的 资源 对 象 的 
信息 ， 则 需要 使 用 -n 或 --namespace 指 明 其 名 称 。 例 如 ， 列 出 kube- 
namespace 名 称 空间 中 拥有 k8s-app 标 签名 称 的 所 有 Pod 对 象 


$kubect1 get pods-l1 k8s-app-n kube-system 


3. 打 印 资源 对 象 的 详细 信息 


每 个 资源 对 象 都 包含 着 用 户 期 望 的 状态 (Spec) 和 现 有 的 实际 状 
态 (Status) 两 种 状态 信息 , “kubectl get-o{fyamlljjosn}” 或 “kubectl 
describe” 命 令 都 能 够 打印 出 指定 资源 对 象 的 详细 描述 信息 。 例 如 ， 查 
看 kube-system 名 称 空 间 中 拥有 标签 component=kube-apiserver 的 Pod 对 
象 的 资源 配置 清单 〈 期 望 的 状态 ) 及 当前 的 状态 信息 ， 并 输出 为 yaml 
格式 ， 命 令 如 下 : 


$kubectl1 get pods- component=kube-apiserver-o yaml-n kube-system 


而 “kubectl describe” 命 令 还 能 显示 与 当前 对 象 相关 的 其 他 资源 对 
象 ， 如 Event 或 Controller 等 。 例 如 ， 查 看 kube-system 名 称 空 间 中 拥有 标 
签 component=kube-apiserver 的 Pod 对 象 的 详细 描述 信息 ， 可 以 使 用 下 面 


$kubect1 describe pods-l1 component=kube-apiserver-n kube-system 


这 两 个 命令 都 支持 以 “TYPE NAME” 或 “TYPE/NAME” 的 格式 指定 
具体 的 资源 对 象 ， 如 “pods kube-apiserver-master.ilinux.io” 或 “pods/kube- 
apiserver-masterilinux.io”， 以 了 解 特定 资源 对 象 的 详细 属性 信息 及 状 


4. 打 印 容器 中 的 日 志 信 息 


通常 一 个 容 妖 中 仪 会 运行 一 个 进程 (及 其 子 进程 ， 此 进程 作为 

PID 为 1 的 进程 接收 并 人 处理 管理 信息 ， 同 时 将 日 志 直 接 输 出 至 终端 中 ， 
而 无 须 再 像 传统 的 多 进程 系统 环境 那样 将 日 志保 存 于 文件 中 ， 因 此 容 
堪 日 志 信 息 的 获取 一 般 要 到 其 控制 上 进行 。“kubectl logs” 命 令 可 打印 
Pod 对 象 内 指定 容 融 的 日 志 人 信息， 命令 格式 为 “kubectl logs[-f][-p] 

(PODITYPE/NAME) [-cCONTAINER][options]”， 若 Pod 对 象 内 仅 有 
一 个 容器 ， 则 -c 选 项 及 容器 名 为 可 选 。 例 如 ， 查 看 名 称 空间 kube- 
system 中 仪 有 一 个 容 姻 的 Pod 对 象 kube-apiserver-master.ilinux.io 的 日 
二 二 


/JUN，。 


$kubect1 logs kube-apiserver-master.ilinux.io-n kube-system 


为 上 面 的 命令 请 加 “- 妊 选项 ， 还 能 用 于 择 续 监控 指定 容 右 中 的 日 
志 输 出 ， 其 行为 类 似 于 使 用 了 -f 选 项 的 tail 命 令 。 


5. 在 容 右 中 执行 命令 


容 需 的 隔离 属性 使 得 对 其 内 部 信息 的 获取 变 得 不 再 直观 ， 这 一 点 
在 用 户 需 要 了 解 容 器 内 进程 的 运行 特性 、 文 件 系统 上 的 文件 及 路 径 布 
局 等 信息 时 ， 需 要 穿 透 其 隔离 边界 进行 。“kubectl exec” 命 令 便 是 用 于 
在 指定 的 容器 内 运行 其 他 应 用 程序 的 命令 ， 例 如 ， 在 kube-system 名 称 
全 间 中 的 Pod 对 象 kube-apiserver-master.ilinux.io 上 的 唯一 容器 中 运行 ps 
HH 人 >: 


$kubect1 exec kube-apiserver-master.ilinux.io-n kube-system--ps 


注意 ， 震 Pod 对 象 中 存在 多 个 容 郁 ， 则 需要 以 -c 选 项 指定 容 规 后 再 


6. 删 除 资源 对 象 


使 命 已 经 完成 或 存在 错误 的 资源 对 象 可 使 用 “kubectl delete” 命 令 予 
以 删除 ， 不 过 ， 对 于 受 控 于 控制 器 的 对 象 来 说， 删除 之 后 其 控制 器 可 
能 会 重建 出 类 似 的 对 象 ， 例 如 ，Deployment 控 制 絮 下 的 Pod 对 象 在 被 市 
除 J 被 重建 。 例 如 ， 删 除 默认 名 称 空间 中 名 为 nginx-svc 的 Service 
资 小 1X, : 


$kubect1 delete services nginx-svc 


下 面 的 命令 可 用 于 删除 kube-system 名 称 空间 中 拥有 标签 “k8s- 
app=kube-proxy” 的 所 有 Pod 对 象 : 


$kubect1 delete pods- app=monitor-n kube-system 


若 要 删除 指定 名 称 空 间 中 的 所 有 的 某 类 对 和 象 ， 可 以 使 用 “kubectl 
delete TYPE--all-n NS” 命 令 ， 例 如 ， 删 除 kube-public 名 称 空间 中 的 所 有 


Pod 对 和 象 : 


$kubect1 delete pods--all-n kube-public 


另外 ， 有 些 资源 类 型 (如 Pod) ,支持 优 雅 删除 的 机 制 ， 它 们 有 
着 默认 的 删除 宫 限 期 ， 不过， 用 户 可 以 在 命令 中 使 用 --grace-period 远 
项 或 -now 选 项 来 复 兰 默认 的 宽 限 期 。 


2.4 ”命令 式 容 如 应 用 编排 


本 将 使 用 示例 镜像 *ikubernetes/myapp: V1” 来 演示 容 妮 应 用 编排 
的 基础 操作 : 应 用 部 署 、 访 问 、 查 看 、 服 务 骏 露 和 扩 缩 容 等 。 一 般 说 
来 ，Kubernetes 之 上 应 用 程序 的 基础 管理 操作 由 如 下 几 个 部 分 组 成 。 


1) 通过 合用 的 Controller 类 的 资源 (如 Deployment 或 
ReplicationController) 创建 并 管控 Pod 对 象 以 运行 特定 的 应 用 程序 ， 如 
Nginx 或 tomcat 等 。 无 状态 (stateless) 应 用 的 部 署 和 控制 通常 使 用 
Deployment 控 制 右 进行 ， 而 有 状态 应 用 则 需要 使 用 StatefulSet 探 制 炙 。 


2) 为 Pod 对 象 创建 Service 对 象 ， 以 便 疝 客户 端 提供 固定 的 访问 路 
径 ， 并 借助 于 CoreDNS 进 行 服 务 发 现 。 


本 3) 随时 按 需 获取 各 资源 对 象 的 简要 或 详细 信息 ， 以 了 解 其 运行 状 


4UD 


4) 如 有 需要 ， 则 手动 对 文 持 扩 缩 容 的 Controller 组 件 进行 扩容 或 
缩 容 ; 或 者 ， 为 文 持 HPA 的 Controller 组 件 (如 Deployment 或 
ReplicationController) 创建 HPA 资 源 对 象 以 实现 Pod 副 本 数目 的 自动 伸 
缩 。 


5) 滚动 更 新 ， 当 应 用 程序 的 镜像 出 现 新 版 本 时 ， 对 其 执行 更 新 操 
作 ， 必 妆 时 ， 为 Po 对象 中 的 容器 更 新 其 镑 像 版 本 ， 并 可 恨 所 需要 所 
行 回 滚 操作 。 


本 世 中 的 操作 示例 仅 演 示 了 前 三 个 部 分 的 功能 ， 即 应 用 的 部 署 、 
服务 骏 露 及 相关 信息 的 查看 。 应 用 的 扩 缩 容 、 升 级 及 回 滚 等 操作 会 在 
后 面 的 章 市 中 进行 详细 介绍 。 


G 提示 ”以 下 操作 命令 在 任何 部 署 了 kubectl 并 能 正常 访问 到 
Kubernetes 集 群 的 主机 上 均 可 执行 ， 包 括 和 集群 外 的 主机 。 复 制 master 主 
机 上 的 /etc/kubernetes/admin.conf 至 相关 用 户主 目录 下 的 .kube/config 文 
件 即 可 正常 执行 ， 具 体 方法 请 参考 kubeadm init 命 令 结果 中 的 提示 。 


2.4.1 部署 应 用 (Pod) 


在 Kubernetes 集 群 上 自主 运行 的 Pod 对 象 在 非 计 划 内 终止 后 ， 其 生 
命 周 期 即 告 结束 ， 用 户 需要 再 次 手动 创建 类 似 的 Pod 对 象 才 能 确保 其 容 
铬 中 的 应 用 依然 可 得 。 对 于 Pod 数 量 众多 的 场景 ， 尤 其 是 对 微服 务 业 务 
来 说 ， 用 户 必 将 疲 于 应 付 此 类 需求 。Kubernetes 的 工作 负载 
(workload) 类 型 的 控制 器 能 够 自动 确保 由 其 管控 的 Pod 对 象 按 用 户 期 
望 的 方式 运行 ， 因 此 ，Pod 的 创建 和 管理 大 多 都 会 通过 这 种 类 型 的 控制 
铬 来 进行 ， 包 括 Deployment 、ReplicaSet、ReplicationController 等 。 


1. 创 建 Deployment 控 制 器 对 象 


“kubectl run”* 命 令 可 于 命令 行 直 接 创 建 Deployment 控 制 咽 ， 并 以 -- 
image 选 项 指定 的 镜像 运行 Pod 中 的 容 矿 ，--dry-run 选 项 可 用 于 命令 的 测 
试 运行 ， 但 并 未 真正 执行 资源 对 象 的 创建 过 程 。 例 如 ， 下 面 的 命令 要 
创建 一 个 名 为 myapp 的 Deployment 探 制 器 对 象 ， 它 使 用 镜像 
ikubernetes/myapp: v1 创 建 Pod 对 象 ， 但 仅 在 测试 运行 后 即 退出 : 


~]$ kubectl run myapp --image=Ikubernetes/myapp:Vv1 --port=80 --replicas=1 
--dry-run 

NAME AGE 

myapp <Unknown> 


镜像 ikubernetes/myapp: v1 中 定义 的 容器 主 进程 为 默认 监听 于 80 端 
口 的 web 服务 程序 Nginx， 因 此 ， 如 下 命令 使 用 “--port=80" 来 指明 容器 
要 暴 露 的 端口 。 而 “--replicas=12? 选 项 则 指定 了 目标 控制 器 对 象 要 目 动 创 
建 的 Pod 对 象 的 副本 数量 。 确 认 测 试 命令 无 误 后 ， 可 移 除 “--dry-run” 选 
项 后 再 次 执行 命令 以 完成 资源 对 象 的 创建 : 


~]$ kubect] run myapp --image=ikubernetes/myapp:v1i --port=80 --replicas=1 
deployment .apps/myapp created 


创建 完成 后 ， 其 运行 效果 示意 图 如 图 2-10 所 示 ， 它 在 default 名 称 空 
间 中 创建 了 一 个 名 为 myapp 的 Deployment 控 制 器 对 象 ， 并 由 它 基于 指定 
的 镜像 文件 创建 了 一 个 Pod 对 和 象 。 


kubectl 


Kubernetes 
Cluster 


Selector 


图 2-10 ”Deployment 对 象 myapp 及 其 创建 的 Pod 对 象 


kubectl run 命 令 其 他 常用 的 选项 还 有 如 下 几 个 ， 它 们 支持 用 户 在 创 
府 资 源 对 象 时 实现 更 多 的 控制 ， 具 体 如 下 。 


.-]，--labels: 为 Pod 对 象 设 定 自 定义 标签 。 


--record: 是 否 将 当前 的 对 象 创建 命令 保存 至 对 象 的 Annotation 
中 ， 布 尔 型 数据 ， 其 值 可 为 true 或 false。 


--save-config: 是 否 将 当前 对 象 的 配置 信息 保存 至 Annotation 中 ， 
布尔 型 数据 ， 其 值 可 为 true 或 false 。 


--restart=Never: 创建 不 受 控 制 絮 管控 的 自主 式 Pod 对 象 。 


其 他 可 用 选项 及 使 用 方式 可 通过 “kubectl run--help” 命 令 获 取 。 资 源 
对 象 创 建 完成 后 ， 通 党 需要 了 解 其 当前 状态 是 否 正常 ， 以 及 是 否 能 够 


吻合 于 用 户 期 望 的 目标 状态 ， 相 关 的 操作 一 般 使 用 kubectl get、kubectl 


describe 等 命令 进行 。 
2. 打 印 资源 对 象 的 相关 信息 


kubectl get 命 令 可 用 于 获取 各 种 资源 对 象 的 相关 信息 ， 它 既 能 够 显 
示 对 象 类 型 特有 格式 的 简要 信息 ， 也 生 让 定 出 格式 为 YAMT 或 JSON 
的 详细 信息 ， 或 者 使 用 Go 模板 目 定义 要 显示 的 属性 及 信息 请 。 例如 ， 
面 基 吉 看 前 面 创 建 的 Deployment 对 象 的 相关 运行 状态 的 命 命令 及 其 输 


ee kubectl1 和 deployments 
RED CURRENT UP-TO-DATE AVAILABLE AGE 
中 和 1 1 1 1m 


上 面 命令 的 执行 结果 中 ， 各 字段 的 说 明 具 体 如 下 。 
1) NAME: 资源 对 象 的 名 称 。 
2) DESIRED: 用 户 期 望 由 当前 控制 器 管理 的 Pod 对 象 副 本 的 精确 


数量 。 


3) CURRENT: 当前 控制 器 已 有 的 Pod 对 象 的 副本 数量 。 


4) UP-TO-DATE: 更 新 到 最 新 版 本 定义 的 Pod 对 象 的 副本 数量 ， 在 
控制 器 的 滚动 更 新 模式 下 ， 它 表示 已 经 完成 版 本 更 新 的 Pod 对 象 的 副本 


数量 。 


5) AVAILABLE: 当前 处 于 可 用 状态 的 Pod 对 象 的 副本 数量 ， 即 可 
正常 提供 服务 的 副本 数 。 


6) AGE: Pod 的 存在 时 长 。 


@ 提示 。 “ Deployment 资源 入 对 象 通过 ReplicaSet 控 制 器 实例 完成 对 
Pod 对 和 象 的 控制 ， 而 非 直 接 控 制 。 另 外 ， 通 过 控制 器 创建 的 Pod 对 象 都 
会 被 自动 附加 一 个 标签 ， 其 格式 为 “run=<Controller_Name>”， 例 如 ， 

上 面 的 命令 所 创建 的 Pod， 会 拥有 “run=myapp” 标 签 。 后 面 的 章节 对 此 
会 有 详细 描述 。 


而 此 Deployment 控 制 句 创建 的 唯一 Pod 对 象 运行 正常 与 否 ， 其 被 调 
度 至 哪个 节点 运行 ， 当 前 是 否 就 绪 等 也 是 用 户 在 创建 完成 后 应 该 重点 
关注 的 信息 。 由 控制 器 创建 的 Pod 对 象 的 名 称 通 常 是 以 控制 器 名 称 为 前 
级 ， 以 随机 字符 为 后 级 ， 例 如 ， 下 面 命令 输出 结果 中 的 myapp- 
6865459dff-5nsjc: 


$ kubectl1 get pods -o wide 

NAME READY STATUS RESTARTS AGE IP NODE 

myapp-6865459dff-5nsjc 1/1 Running 0 3m 10.244.3.2 node03. 
ilinux.io 


上 面 命令 的 执行 结果 中 ， 个 字段 均 代 表 着 Pod 资 源 对 象 一 个 方 
面 的 属性 ， 除 了 NAME 之 外 的 其 他 字段 及 功用 说 明 如 下 。 


@OREADY: Pod 中 的 容 属 进程 初始 化 完成 并 能 够 正常 前 近 供 服务 时 
即 为 就 绪 状 态 ， 此 字段 用 于 记录 处 于 就 绪 状 态 的 容器 数量 


@STATUS: Pod 的 当前 状态 ， 其 值 可 能 是 Pending 、 Running、 
Succeeded、Failed 和 和 Unknown 等 其 中 之 一 


@RESTARTS: Pod 对 象 可 能 会 因 容 需 进 程 般 总、 超出 资源 限额 等 
原因 发 生 故 障 问题 而 被 重启 ， 此 字段 记录 了 它 重 启 的 次 数 。 


@IP: Pod 的 IP 地 址 ， 其 通常 由 网 络 插件 目 动 分 配 。 
NODE: 创建 时 ，Pod 对 象 会 由 调度 器 调度 至 集群 中 的 某 节 点 运 
行 ， 此 字段 即 为 节点 的 相关 标识 信息 。 


@ = 如 琳 指 定名 称 空间 中 存在 大 量 的 Pod 对 和 象 而 使 得 类 似 
如 上 命令 的 输出 结果 存在 太 多 的 不 相关 信息 时 ， 则 可 通过 指定 选项 -1 
myapp” 进 行 Pod 对 象 过 滤 ， 其 仅 显示 符合 此 标签 选择 右 的 Pod 对 


确认 Pod 对 和 象 已 转 为 “Running” 状 态 之 后 ， 即 可 于 集群 中 的 任 一 

点 (或 其 他 Pod 对 象 ) 直接 访问 其 容器 化 应 用 中 的 服务 ， 如 图 2- es 
点 NodeX 上 的 客户 肖 程 序 Client， 或 者 集群 上 运行 于 Pod 中 的 客户 端 程 
予 O 


kubect 


Kubemetes | 
Cluster | 


default namespace 


Client 


Label 
Selector 


图 2-11 访问 Pod 中 容器 化 应 用 服务 程序 


例如 ， 在 集群 中 任 一 节点 上 使 用 curl 命 令 对 地 址 为 10.244.3.2 的 Pod 
对 象 myapp-6865459dff-5nsjc 的 80 端 口 发 起 服务 请 求 ， 命 令 及 结果 如 下 
所 示 : 


[ik8s@node03 ~]$ curl http://10.244.3.2:80/ 
Hello MyApp | Version: v1 | <a href='"hostname .htm1">Pod Name</a> 


2.4.2 ”探查 Pod 及 应 用 详情 


资源 创建 或 运行 过 程 中 侦 尔 会 因 故 出 现 异常 ， 此 时 用 户 需 要 充分 
获取 相关 的 状态 及 配置 信息 以 便 确 定 问 题 的 所 在 。 男 外 ， 在 对 资源 对 
象 进行 创建 或 修改 完成 之 后 ， 也 需要 通过 其 详细 的 状态 来 了 解 操 作成 
功 与 否 。kubecd 有 多 个 子 命令 可 用 于 从 不 同 的 角度 显示 对 和 象 的 状态 信 
思 ， 这 些 信息 有 助 于 用 户 了 解 对 象 的 运行 状态 、 属 性 详情 等 信息 。 


1) kubectl describe: 显示 资源 的 详情 ， 包 括 运行 状态 、 事 件 等 信 
息 ， 但 不 同 的 资源 类 型 其 输出 内 容 不 尽 相 同 。 


2) kubectl logs: 查看 Pod 对 象 中 容 融 输 出 在 控制 台 的 日 志 信息 。 
在 Pod 中 运行 有 多 个 容 顺 时 ， 需 要 使 用 选项 <“-c" 指 定 容 硕 和 名 称 。 


3) kubectl exec: 在 Pod 对 象 某 容器 内 运行 指定 的 程序 ， 其 功能 类 
似 于 “docker exec” 命 令 ， 可 用 于 了 解 容器 各 方面 的 相关 信息 或 执行 必 
需 的 设 定 操 作 等 ， 其 具体 功能 取决 于 容器 内 可 用 的 程序 。 


1. 查 看 Pod 对 象 的 详细 描述 
下 面 给 出 的 命令 打印 了 此 前 由 myapp 创 建 的 Pod 对 象 的 详细 状态 信 


息 ， 为 了 便于 后 续 的 多 次 引用 ， 这 里 先 将 其 名 称 保存 于 变量 
POD_NAME 中 。 命 令 的 执行 结果 中 省 略 了 部 分 输出 : 


~]$ POD_NAME=myapp-6865459dff-5nsjc 
~]$ kubect1 describe pods $POD_NAME 


Name : myapp-6865459dff-5nsjc 
Namespace: default 
Priority: 0 
PriorityClassName: <none> 
Node: node03.ilinux.i0o/172.16.0.68 
Status: Running 
IP : 10.244.3.2 
Controlled By: ReplicaSet/myapp-6865459dff 
Containers: 
myapp: 
Events: 
Type Reason Age From Message 


default/myapp-6865459dff-5nsjc to node03.ilinux.io 


Normal Pulling 55m kubelet, node03.ilinux.io pulling image "ikubernetes/ 
myapp:vi1" 

Normal Pulled 54m kubelet, node03.ilinux.io Successfully pulled image 
"ikubernetes/myapp:vi1" 

Normal Created 54m kubelet, node03.ilinux.io Created container 

Normal Started 54m kubelet, node03.ilinux.io Started container 


不 同 的 需求 场景 中 ， 用 户 需 要 关注 不 同 纬度 的 输出 ， 但 一 般 来 
说 ，Events 和 Status 字 上段 会 是 重点 关注 的 对 象 ， 它 们 分 别 代 表 了 Pod 对 
象 运行 过 程 中 的 重要 信息 及 当前 状态 。 上 面 命令 执行 结果 中 的 不 少 字 
段 都 可 以 见 名 而 知 义 ， 而 且 部 分 字段 在 前 面 介 绍 其 他 命令 输出 时 已 经 
给 出 ， 还 有 一 部 分 会 在 本 书后 面 的 篇 幅 中 给 予 介 绍 。 


2 种 看 窟 部 目 志 


Docker 容 需 一 般 仅 运 行 单 个 应 用 程序 ， 其 日 志 信息 将 通过 标准 错 
误 和 输出 等 方式 直接 打印 至 控制 台 , “kubectl logs” 命 令 即 用 于 查看 这 些 
志 。 例 如 ， 查 看 由 Deployment 控 制 妖 myapp 创 建 的 Pod 对 象 的 控制 台 
日 志 ， 命 令 如 下 : 


~]$ kubect1 logs $POD_NAME 
10.244.3.1 - - [......] "GET / HTTP/1.1" 200 65 "-" "curl/7.29.0" "-" 


如 果 Pod 中 运行 有 多 个 容器 ， 则 需要 在 查看 日 志 时 为 其 使 用 “-c”* 选 
项 指定 容器 名 称 。 例 如 ， 当 读者 所 部 署 的 是 KubeDNS 附 件 而 非 
CoreDNS 时 ，kube-system 名 称 空间 内 的 kube-dns 相 关 的 Pod 中 同时 运行 
着 kubedns、dnsmasq 和 sidecar 三 个 容器 ， 如 采 要 查看 kubedns 容 妖 的 日 
志 ， 需 要 使 用 类 似 如 下 的 命令 : 


~]$ DNS_POD=$(kubect]1 get pods -o name -n kube-system | grep kube-dns) 
~]$ kubect1 logs $DNS_POD -c kubedns -n kube-system 


需要 注意 的 是 ， 日 志 查 看 命令 仅 能 用 于 打印 存在 于 Kubernetes 系 
统 上 的 Pod 中 容 名 的 日 志 ， 对 于 已 经 删除 的 Pod 对 象 ， 其 容器 日 志 信 息 
将 无 从 获取 。 日 志 信 息 是 用 于 辅助 用 户 获 取 容 器 中 应 用 程序 运行 状态 
的 最 有 效 的 途径 之 一 ， 也 是 非常 重要 的 排 错 手 段 ， 因 此 通常 需要 使 用 
集中 式 的 日 志 服 务 右 统一 收集 存储 于 各 Pod 对 象 中 容 句 的 日 志 信 息 。 


3. 在 容 右 中 运行 额外 的 程序 


运行 着 非 交 互 式 进程 的 容器 中 ， 上 默认 运行 的 唯一 进程 及 其 子 进程 
局 动 后 ， 容 器 即 进入 独立 、 隔 离 的 运行 状态 。 对 容器 内 各 种 详情 的 了 
解 需 要 罕 透 容器 边界 进入 其 中 运行 其 他 的 应 用 程序 来 进行 ，“kubectl 
exec” 吕 以 让 用 户 在 Pod 的 某 容 器 中 运行 用 户 所 需要 的 任何 存在 于 容器 
中 的 程序 。 在 “kubectl logs” 获 取 的 信息 不 够 全 面 时 ， 此 命令 可 以 通过 
在 Pod 中 运行 其 他 指定 的 命令 (前提 是 容器 中 存在 此 程序 ， 来 辅助 用 
户 获 取 更 多 的 信息 。 一 个 更 便捷 的 使 用 接口 的 方式 是 直接 交互 式 运 行 
容 姨 中 的 某 个 Shell 程 序 。 例 如 ， 直 接 查 看 Pod 中 的 容 锅 运行 的 进程 : 


~]$ kubectl1 exec $POD_NAME ps aux 


PID USER TIME COMMAND 
1 root 0:00 nginx: master process nginx -g daemon off; 
8 nginx 0:00 nginx: worker process 
9 root 0:00 ps aux 


/SS | 
QS 注音 ”如 果 pod 对 象 中 运行 了 多 个 容 
还 需要 使 用 “-c<container name>” 选 项 指定 要 


名 称 。 


若 要 进入 容器 的 交互 式 Shell 接 口 ， 可 使 用 类 似 如 下 的 命令 ， 斜体 
部 分 表示 在 容器 的 交互 式 接口 中 执行 的 命令 : 


TI 


， 那 么 在 程序 运行 时 
内 部 运行 程序 的 容器 


S 


~]$ kubect1 -it exec $POD_NAME /bin/sh 

/ # hostname 

myapp-6865459dff-5nsjc 

/# netstat -tnl 

Active Internet connections (only servers) 

Proto Recv-Q Send-Q Local Address Foreign Address State 

tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 
/ # 


2.4.3 部署 Service 对 象 


简单 来 说 ， 一 个 Service 对 象 可 视 作 通过 其 标签 选择 器 过 小 出 的 一 
组 Pod 对 象 ， 并 能 够 为 此 组 Pod 对 象 监听 的 套 接 字 提 供 端口 代理 及 调度 


服务 。 
1. 创 建 Service 对 和 象 
“kubectl expose” 命 令 可 用 于 创建 Service 对 象 以 将 应 用 程序 “ 骏 


露 ” (expose) 于 网 络 中 。 人 例如， 下面 的 命令 即 可 将 myapp 创 建 的 Pod 对 
和 象 使 用 “NodePort” 类 型 的 服务 暴露 到 集群 外 部 : 


~]$ kubectl] expose deployments/myapp --type="NodePort" --port=80 --name=myapp 
service "myapp" exposed 


上 面 的 命令 中 ，--type 选 项 用 于 指定 Service 的 类 型 ， 而 --port 则 用 于 
指定 要 又 圳 的 容 恬 站 日 目 标 Service 对 象 的 名 称 为 myapp。 创建 完成 
后 ，default 名 称 空间 中 的 对 象 及 其 通信 示意 图 如 图 2-12 所 示 。 


kubect myapp Clients 


Kubernetes ; 
Cluster 


default namespace 
myapp 
Client 
Label 
Selector ClusterIP:Port 


图 2-12 ”Service 对 象 在 Pod 对 象 前 端 添 加 了 一 个 固定 访问 层 


下 面 通 过 运行 于 同一 集群 中 的 Pod 对 象 中 的 客户 端 程序 发 起 访问 测 
试 ， 来 模拟 图 2-12 中 的 源 自 myapp Client Pod 对 象 的 访问 请 求 。 首 先 ， 
使 用 kubectl run 命 令 创建 一 个 Pod 对 象 ， 并 直接 接 入 其 交互 式 接口 ， 如 
下 命令 的 -it 组 合 选 项 即 用 于 交互 式 打 开 并 保持 其 shell 命 令 行 接口 ， 而 后 
通过 wget 命 令 对 此 前 创建 的 Service 对 象 的 名 称 发 起 访问 请 求 ， 如 下 命 
令 中 的 myapp 即 Service 对 象 名 称 ，default 即 其 所 属 的 Namespace 对 象 的 
名 称 : 


$ kubectl run client --image=busybox --restart=Never -it -- /bin/sh 
If you don't see a command prompt, try pressing enter. 

/ # wget -0 - -q http://myapp.default:80 

Hello MyApp | Version: v1 | <a href="hostname.html">Pod Name</a> 


创建 时 ，Service 对 象 名 称 及 其 ClusterIP 会 由 CoreDNS 附 件 动态 添加 
I 因此 ， 名 称 解 析 服 务 在 对 象 创建 后 即 可 直接 使 


类 似 于 列 出 Deployment 控 制 器 及 Pod 对 象 的 方式 , “kubectl get 
services” 命 令 能 够 列 出 Service 对 象 的 相关 信息 ， 例 如 下 面 的 命令 显示 了 
Service 对 象 myapp 的 简要 状态 信息 : 


~]$ kubect1 get svc/myapp 
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE 
myapp NodePort 10.109.39.145 <none> 80:31715/TCP 5m 


其 中 ,，“PORT (s) ”字段 表明 ， 集 群 中 各 工作 节点 会 捕获 发 往 本 地 
的 目标 端口 为 31715 的 流量 ， 并 将 其 代理 至 当前 Service 对 象 的 80 端 口 ， 
于 是 ， 集 群 外 部 的 用 户 可 以 使 用 当前 集群 中 任 一 和 点 的 此 端口 来 请 求 
Service 对 象 上 的 服务 。CLUSTER-IP 字 段 为 当前 Service 的 IP 地 址 ， 它 是 
一 个 虚拟 IP， 并 没有 配置 于 集群 中 的 任何 主机 的 任何 接口 之 上 ， 但 每 
个 node 之 上 的 kube-proxy 都 会 为 CLUSTER-IP 所 在 的 网 络 创建 用 于 转发 
的 iptables 或 ipvs 规 则 。 些 时， 用 户 可 于 集群 外 部 任 一 浏览 器 请 求 集群 任 
一 节点 的 相关 端口 来 进行 访问 测试 。 


创建 Service 对 象 的 另 一 种 方式 是 使 用 "kubectl create service” 命 令 ， 
对 应 于 每 个 类 型 ， 它 分 别 有 一 个 专用 的 子 命令 ， 例 如 “kubectl create 
service clusterip” 和 “kubectl create service nodeport” 和 等， 各 命令 在 使 用 方 


式 上 也 略 有 区 别 。 
2. 查 看 Service 资 源 对 象 的 描述 
“kubectl describe services” 命 令 用 于 打印 Service 对 象 的 详细 信息 ， 它 


通常 包括 Service 对 象 的 Cluster IP， 关 联 Pod 对 象 时 使 用 的 标签 选择 器 及 
关联 到 的 Pod 资 源 的 端点 等 ， 示 例如 下 : 


~]$ kubectl describe services myapp-svc 


Name: myapp 
Namespace: default 

Labels: run=myapp 
Annotations: <none> 
Selector: run=myapp 

Type: NodePort 

IP: 10.109.39.145 
Port: <unset> 80/TCP 
TargetPort: 80/TCP 

NodePort : <unset> 31715/TCP 
Endpoints: 10.244.3.2:80 
Session Affinity: None 


External Traffic Policy: Cluster 
Events: <none> 


上 面 命令 的 执行 结果 输出 基本 上 可 以 做 到 见 名 而 知 义 ， 此 处 需要 
等 别 说 明 的 几 个 字段 具体 如 下 : 


1) Selector 当前 Service 对 象 使 用 的 标签 选择 器 ， 用 于 选择 关联 的 
Pod 对 和 象 。 


2) Type: 即 Service 的 类 型 ， 其 值 可 以 是 ClusterITP、NodePort 和 
LoadBalancer 等 其 中 之 一 。 


3) IP: 当前 Service 对 象 的 ClusterIP。 


4) Port: 炊 露 的 端口 ， 即 当前 Service 用 于 接收 并 响应 请 求 的 端 
器。 


5) TargetPort 容器 中 的 用 于 暴露 的 目标 端口 ， 由 Service Port 路 由 
请 求 至 此 端口 。 


6) NodePort: 当前 Service 的 NodePort， 它 是 否 存 在 有 效 值 与 Type 
字段 中 的 类 型 相关 。 


7) EndPoints: 后 端 端点 ， 即 被 当前 Service 的 Selector 挑 中 的 所 有 
Pod 的 IP 及 其 端口 。 


8) Session Affinity: 是 否 启用 会 话 粘性 。 


9) External Traffic Policy: 外 部 流量 的 调度 策略 。 


2.4.4 扩容 和 缩 容 


前 面 示例 中 创建 的 Deployment 对 象 myapp 仅 创建 了 一 个 Pod 对 象 ， 
其 所 能 够 承载 的 访问 请 求 数量 即 受 限于 这 单个 Pod 对 象 的 服务 容量 。 请 
求 流量 上 升 到 接近 或 超出 其 容量 之 前 ， 用 户 可 以 通过 Kubernetes 的 “ 扩 
容 机 制 ? 来 扩展 Pod 的 副本 数量 ， 从 而 提升 其 服务 容量 。 


简单 来 说 ， 所 谓 的 “伸缩 ”(Scaling) 就 是 指 改 变 特定 控制 器 上 Pod 
副本 数量 的 操作 ，“ 扩 容 ”(scaling up) 即 为 增加 副本 数量 ， 而 “ 缩 
容 ” (scaling down) 则 意 指 缩减 副本 数量 。 不 过 ， 无 论 是 扩容 还 是 缩 
容 ， 其 数量 都 需要 由 用 户 明 确 给 出 。 


Service 对 象 内 建 的 负载 均衡 机 制 可 在 其 后 端 副本 数量 不 止 一 个 时 
目 动 进行 流量 分 发 ， 它 还 会 目 动 监控 关联 a 到 的 Pod 的 健康 状态 ， 以 确 祭 
仅 将 请 求 流量 分 发 至 可 用 的 后 端 Pod 对 象 。 若 某 Deployment 控 制 器 管理 
包含 多 个 Pod 实 例 ， 则 必要 时 用 户 还 可 以 为 其 使 用 "滚动 更 新 ”机 制 将 其 
容器 镜像 升级 到 新 的 版 本 或 变更 那些 支持 动态 修改 的 Pod 属 性 。 


使 用 kubectl run 命 令 创 建 Deployment 对 象 时 ,， “--replicas=” 选 项 能 够 
指定 由 该 对 象 创建 或 管理 的 Pod 对 象 副 本 的 数量 ， 日 其 数量 支持 运行 时 
进行 修改 ， 并 立即 生效 。“kubectl scale” 命 令 就 是 专用 于 变动 控制 器 应 
用 规模 的 命令 ， 它 支持 对 Deployment 资 源 对 象 的 扩容 和 缩 容 操 作 。 例 
ee 则 可 以 使 用 如 下 命令 来 
ID : 


~]$ kubectl] scale deployments/myapp --replicas=3 
deployment .extensions "myapp" scaled 


而 后 列 出 由 myapp 创 建 的 Pod 副 本 ， 确 认 其 扩展 操作 的 完成 状态 。 
如 下 命令 显示 出 其 Pod 副 本 数量 已 经 扩 增 至 3 个 ， 其 中 包括 此 前 的 
myapp-6865459dff-5nsjc: 


~]$ kubect] get pods -1 run=myapp 


NAME READY STATUS RESTARTS AGE 
myapp-6865459dff-52]j7t 0/1 ContainerCreating 0 53s 
myapp-6865459dff-5nsjc 1/1 Running 0 2h 


myapp-6865459dff-jz7t6 0/1 ContainerCreating 0 53s 


Deployment 对 象 myapp 规 模 扩 展 完成 之 后 ，default 名 称 空 间 中 的 资 
源 对 象 及 其 关联 关系 如 图 2-13 所 示 。 


kubectl myapp Clients 


| NodeIP:NodePort; Kubernetes 


Cluster 


myapp 
Client 


' 


图 2-13 ”Deployment 对 象 规模 扩 增 完成 


而 后 由 “kubectl describe deployment” 命 令 打印 Deployment 对 和 象 
myapp 的 详细 信息 ， 了 解 其 应 用 规模 的 变动 及 当前 Pod 副 本 的 状态 等 相 
关 信 息 。 从 下 面 的 命令 结果 可 以 看 出 ， 其 Pod 副 本 数量 的 各 项 指标 都 已 
经 转换 到 了 新 的 目标 数量 ， 而 其 事件 信息 中 也 有 相应 的 事件 显示 其 扩 
增 操 作 已 成 功 完 成 : 


~]$ kubect] describe deployments/myapp 

Name: myapp 

Selector: run=myapp 

Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 


unavailable 


Type Reason Age From Message 


myapp-6865459dff to 3 


由 myapp 自 动 创建 的 Pod 资 源 全 都 拥有 同一 个 标签 选择 
器 “run=myapp”， 因 此 ， 前 面 创 建 的 Service 资 源 对 象 myapp 的 后 端 端点 
也 已 经 通过 标签 选择 器 上 自动 扩展 到 了 这 3 个 Pod 对 象 相 关 的 端点 ， 如 下 
面 的 命令 结果 及 图 2-13 所 示 : 


~]$ kubectl describe services/myapp 
Name: myapp 


Endpoints: 10.244.1.3:80,10.244.2.2:80,10.244.3.2:80 


回 到 此 前 创建 的 客户 端 Pod 对 象 client 的 交互 式 接口 ， 对 Service 对 象 
myapp 反 复发 起 测试 请 求 ， 即 可 验 正 其 负载 均衡 的 效果 。 由 如 下 命令 及 
其 结果 可 以 看 出 ， 它 会 将 请 求 调度 至 后 端的 各 Pod 对 象 进行 处 理 : 


~]$ / # while true; do wget -0 - -q http://myapp.default:80/hostname.html; 
sleep 1; done 

myapp-6865459dff-jz7t6 

myapp-6865459dff-52j7t 

myapp-6865459dff-5nsjc 


应 用 规模 缩 容 的 方式 与 扩容 相似 ， 只 不 过 是 将 Pod 副 本 的 数量 调 至 
比 原 来 小 的 数字 即 可 。 例 如 ， 将 myapp 的 Pod 副 本 缩减 至 2 个 ， 可 以 使 用 
wl 坟 何 : 


~]$ kubect] scale deployments/myapp --replicas=2 
deployment .extensions "myapp" scaled 


至 此 ， 功 能 基本 完整 的 容器 化 应 用 已 在 Kubernetes 上 部 署 完成 ， 即 
人 通过 合适 的 镜像 以 类 似 的 方式 就 
能 部 署 完成 。 


2.4.5 ”修改 及 删除 对 象 
成 功 创建 于 Kubernetes 之 上 的 对 象 也 称 为 活动 对 象 (live 


object) ， 其 配置 信息 (live object configuration) 由 API Server 保 存 于 
集群 状态 存储 系统 etcd 中 , “kubectl get TYPE NAME-o yaml” 命 令 可 获 
取 到 相关 的 完整 信息 ， 而 运行 “kubectl edit”* 命 令 可 调用 默认 编辑 器 对 
活动 对 象 的 可 配置 属性 进行 编辑 。 例 如 ， 修 改 此 前 创建 的 Service 对 象 
myapp 的 类 型 为 ClusterIP， 使 用 “kubectl edit service myapp” 命 令 打 开 编 
辑 界 面 后 修改 type 属 性 的 值 为 ClusterIP， 并 删除 NodePort 属 性 ， 然 后 保 
存 即 可 。 对 活动 对 象 的 修改 将 实时 生效 ， 但 资源 对 象 的 有 些 属性 并 不 
文 持 运 行 时 修改 ， 此 种 情况 下 ， 编 辑 句 将 不 允许 保存 退出 。 

有 些 命 令 是 kubectl edit 命 令 某 一 部 分 功能 的 二 次 封装 ， 例 如 ， 
kubectl scale 命 令 不 过 是 专用 于 修改 资源 对 象 的 replicas 属 性 值 而 已 ， 它 
也 同样 直接 作用 于 活动 对 象 。 


不 再 有 价值 的 活动 对 象 可 使 用 “kubectl delete” 命 令 予 以 删除 ， 需 要 
删除 Service 对 象 myapp 时 ， 使 用 如 下 命令 即 可 完成 : 


~]$ kubect1 delete service myapp 
service "myapp" delete 


有 时候 需要 清空 某 一 类 型 下 的 所 有 对 象 ， 只 需要 将 上 面 命令 对 象 
的 名 称 换 成 “--all* 选 项 便 能 实现 。 例 如 ， 删 除 默 认 名 称 空间 中 所 有 的 
Deployment 控 制 妖 的 命令 如 下 : 


~]$ kubectl1 delete deployment --all 
deployment .extensions "myapp" deleted 


需要 注意 的 是 ， 受 控 于 控制 器 的 Pod 对 象 在 删除 后 会 被 重建 ， 删 
除 此 类 对 和 象 需要 直接 删除 其 控制 句 对 象 。 不 过 ， 删 除 控 制 器 时 知 不 想 
删除 其 Pod 对 象 ， 可 在 删除 命令 上 使 用 “--cascade=false” 选 项 。 


虽然 直接 命令 式 管 理 的 相关 功能 强大 且 适 合用 于 操纵 Kubernetes 
资源 对 象 ， 但 其 明显 的 缺点 是 缺乏 操作 行为 以 及 竺 运行 对 象 的 可 信 


源 。 男 外 ， 直 接 命令 式 管理 资源 对 象 存在 较 大 的 局 限 性 ， 它 们 在 设置 
资源 对 象 属性 方面 提供 的 配置 能 力 相当 有 限 ， 而 且 还 有 不 少 资源 并 不 
文 持 命 令 操 作 进 行 创建 ， 例 如 ， 用 户 无 法 创建 市 有 多 个 容 右 的 Pod 对 

象 ， 也 无 法 为 Pod 对 象 创建 存储 卷 。 因 此 ， 管 理 资 源 对 象 更 有 效 的 方 

式 是 基于 保存 有 对 象 配 置信 息 的 配置 请 单 来 进行 。 


2.5 ”本章 小 结 


本 章 着 重 介绍 了 Kubernetes 的 三 个 核心 资源 抽象 Pod、Deployment 
和 Service， 并 在 介绍 了 kubectl 的 基本 用 法 之 后 通过 案例 讲解 了 如 何在 
集群 中 部 署 、 骏 露 、 访 问 及 扩 缩 容 容 絮 化 应 用 ， 具 体 如 下 。 


.Pod 是 运行 容 虱 化 应 用 及 调度 的 原子 单元 ， 同一 个 Pod 中 可 同时 运 
行 多 个 容器 ， 这 些 容器 共享 Mount、UTS 及 Netwotk 等 Linux 内 核 名 称 空 


间 ， 并 且 能 够 访问 同一 组 存储 卷 。 


.Deployment 坪 最 币 见 的 无 状态 应 用 的 控制 硒 ， 它 文 持 应 用 的 扩 缩 
容 、 深 动 更 新 等 操作 ， 为 容器 化 应 用 赋予 了 极 具 弹性 的 功能 。 

'Service 为 弹性 变动 且 存在 生命 周期 的 Pod 对 象 提供 了 一 个 固定 的 
访问 接口 ， 用 于 服务 发 现 和 服务 访问 。 


.kubectl 是 Kubernetes API Server 最 常用 的 客户 端 程序 之 一 ， 它 功能 
强大 ， 特 性 丰富 ， 几 平 能 够 完成 除了 安装 部 署 之 外 的 所 有 管理 操作 。 


第 3 章 ”次 源 管理 基础 


Kubernetes 系 统 的 API Server 基 于 HTTP/HTTPS 接 收 并 响应 客户 端 
的 操作 请 求 ， 它 提供 了 一 种 “基于 资源 ” (resource-based) 的 RESTful 风 
格 的 编程 接口 ， 将 集群 的 各 种 组 件 都 抽象 成 为 标准 的 REST 资 源 ， 如 
Node、Namespace 和 Pod 等 ， 并 文 持 通过 标准 的 HTTP 方 法 以 JSON 为 数 
0 °。 本章 将 着重 摘 述 Kubemetes 的 资源 
管理 方式 。 


3.1 资源 对 象 及 API 群 组 


REST 是 Representational State Transfer 的 缩写 ， 意 为 “表征 状态 转 
移 ”， 它 是 一 种 程序 架构 风格 ， 基 本 元 素 为 资源 (resource) 、 表 征 
(representation) 和 行为 (action) 。 资 源 即 对 象 ， 一 个 资源 通常 意味 
着 一 个 附带 类 型 和 关联 数据 、 支 持 的 操作 方法 以 及 与 其 他 对 象 的 关系 
的 对 象 ， 它 们 是 持 有 状态 的 事物 ， 即 REST 中 的 S (State) 。REST 组 件 
通过 使 用 “表征 ”来 捕获 资源 的 当前 或 预期 状态 并 在 组 件 之 间 传 输 该 表 
征 从 而 对 资源 执行 操作 。 表 征 是 一 个 字 节 序列 ， 由 数据 、 描 述 数据 的 
元 数据 以 及 偶尔 描述 元 数据 的 元 数据 组 成 (通常 用 于 验证 消息 的 完整 
性 ) ， 表 征 还 有 一 些 其 他 常用 但 不 太 精 确 的 名 称 ， 如 文档 、 文 件 和 
HTTP 消 息 实 体 等 。 表 征 的 数据 格式 称 为 媒体 类 型 (media type) ， 常 
用 的 有 JSON 或 XML 。API 客 户 端 不 能 直接 访问 资源 ， 它 们 需要 执行 “ 动 
作 ”(action) 来 改变 资源 的 状态 ， 于 是 资源 的 状态 从 一 种 形式 “ 转 
移 ” (Transfer) 为 另 一 种 形式 。 


资源 可 以 分 组 为 集合 (collection) ， 每 个 集合 只 包含 单一 类 型 的 
资源 ， 并 且 各 资源 间 是 无 序 的 。 当 然 ， 资 源 也 可 以 不 属于 任何 集合 ， 
它们 称 为 单 体 资产。 事实 上， 集合 本 喘 也 是 资源 ， 它 可 以 部 署 于 全 局 
级 别 ， 位 于 API 的 顶层 ， 也 可 以 包含 于 某 个 资源 中 ， 表 现 为 “ 子 集 合 ”。 
集合 、 资 源 、 子 集合 及 子 资 源 间 的 天 系 如 图 3-1 所 示 。 


| ] 
1 ~ 
| 资源 
| | 质 源 


资源 集合 单 体 资源 上 集合 和 子 资源 


图 3-1 集合、 资源 和 子 资源 


Kubernetes 系 统 将 一 切 事 物 都 抽象 为 API 资 源 ， 其 遵循 REST 架 构 风 
格 组 织 并 管理 这 些 资 源 及 其 对 象 ， 同 时 还 支持 通过 标准 的 HTTP 方 法 
(POST、PUT、PATCH、DELETE 和 GET) 对 资源 进行 增 、 删 、 改 、 
查 等 管理 操作 。 不 过 ， 在 Kubemetes 系 统 的 语 境 中 , “资源 ”用 于 表示 “对 
象 ” 的 集合 ， 例 如 ，Pod 资 源 可 用 于 描述 所 有 Pod 类 型 的 对 象 ， 但 本 书 将 
不 加 区 别 地 使 用 资源 、 对 象 和 资源 对 象 ， 并 将 它们 统统 理解 为 资源 类 
型 生成 的 实例 一 对 象 。 


3.1.1 Kubernetes 的 资源 对 象 


依据 资源 的 主要 功能 作为 分 类 标准 ，Kubernetes 的 API 对 象 大 体 可 
分 为 工作 负载 (Workload) 、 发 现 和 负载 均衡 〈Discovery&LB) 、 
配置 和 存储 (Config&Storage) 、 集 群 (Cluster) 以 及 元 数据 
(Metadata) 五 个 类 别 。 它 们 基本 上 都 是 围绕 一 个 核心 目的 而 设计 : 
2 雁 源 ， 从 而 为 容器 化 应 用 提供 更 灵活 、 更 

善 的 操作 与 管理 组 件 ， 如 图 3-2 所 示 。 


Deployment | | Cronjob i 


| es ReplicaSet | StatefulSet | 


A 


Pod * 
Service 一 一 。 一 一 Ingress 
Contaner 


ww 


me 


en Per ete | Secret 


图 3-2 ”Kubernetes 常 用 资源 对 象 


工作 负载 型 资源 用 于 确保 Pod 资 源 对 象 能 够 更 好 地 运行 容器 化 应 

用 ， 上 有 具有 同一 种 负载 的 各 Pod 对 象 需要 以 负载 均衡 的 方式 服务 于 各 请 
求 ， 而 各 种 容 絮 化 应 用 彼此 之 间 需 要 彼此 “发 现 * 以 完成 工作 协同 。Pod 
资源 具有 生命 周期 ， 存 储 型 资源 能 够 为 重 构 的 Pod 对 象 提供 持久 化 的 
数据 存储 机 制 ， 共享 同一 配置 的 Pod 资 源 可 从 配置 型 资源 中 统一 获取 
配置 改动 信息 ， 这 些 资 务 源 作为 配置 中 心 为 管理 容器 化 应 用 的 配置 文件 

提供 了 极为 便捷 的 管理 机 制 。 集 群 型 资源 为 管理 集群 本 身 的 工作 特性 


供 了 配置 接口 ， 而 元 数据 型 资源 册 用 于 配置 集群 内 部 的 其 他 资源 的 
行为 。 


(1) 工作 负载 型 资源 


Pod 是 工作 仙 载 型 资源 中 的 基础 资源 ， 它 负责 运行 容 右 ， 并 为 其 
解决 环境 性 的 依赖 ， 例 如 ， 向 容 絮 注入 共 至 的 或 持久 化 的 存储 卷 、 配 
置信 息 或 密 钥 数据 等 。 但 Pod 可 能 会 因为 货源 超 限 或 万 点 故障 等 原 
而 终止 ， 这 些 非 正常 终止 的 Pod 资 源 需 要 被 重建 ， 不 过 ， 这 类 工作 将 
由 工作 负载 型 的 控制 忌 来 完成 ， 它 们 通 利 也 称 为 pod 控 制 希 。 


应 用 程序 分 为 无 状态 和 有 状态 两 种 类 型 ， 它 们 对 环境 的 依赖 及 工 
作 特 性 有 很 大 的 不 同 ， 因 此 分 属 两 种 不 同类 型 的 Pod 探 制 需 来 管理 ， 
ReplicationController、ReplicaSet 和 Deployment 负 责 管 理 无 状态 应 用 ， 
StatefulSet 用 于 管控 有 状态 类 应 用 。ReplicationController 是 上 一 代 的 控 
制 姻 ， 其 功能 由 ReplicaSet 和 Deployment 人 负责 实现 ， 因 此 几 近 于 废弃 。 
还 有 些 应 用 较为 独特 ， 它 们 需要 在 集群 中 的 每 个 节点 上 运行 单个 Pod 
资源 ， 负 责 收 集 日 志 或 运行 系统 服务 等 任务 ， 这 些 Pod 资 源 的 管理 则 
属于 DaemonSet 控 制 器 的 分 内 之 事 。 另 外 ， 有 些 容 怖 化 应 用 需要 继续 
运行 以 为 守护 进程 不 同 断 地 提供 服务 ， 而 有 些 则 应 该 在 正常 完成 后 退 
出 ， 这 些 在 正常 完成 后 就 应 该 退出 的 容 絮 化 应 用 则 由 Job 控 制 絮 负责 管 
控 。 下 面 是 各 Pod 控 制 妖 更 为 详细 的 说 明 。 


.ReplicationController: 用 于 确保 每 个 Pod 副 本 在 任 一 时 刻 均 能 满足 
目标 数量 ， 换 言 之 ， 它 用 于 保证 每 个 容器 或 容 需 组 总 是 运行 并 且 可 访 
问 ; 它 是 上 一 代 的 无 状态 Pod 应 用 控制 右 ， 建 议 读者 使 用 新型 控制 壤 
Deployment 和 ReplicaSet 来 取代 它 。 


.ReplicaSet:， 新 一 代 ReplicationController， 它 与 
ReplicationController 的 唯一 不 同 之 处 仅 在 于 文 持 的 标签 选择 器 不 同 ， 
ReplicationController 只 支持 等 值 选 择 器 ， 而 ReplicaSet 还 额外 支持 基于 
集合 的 选择 絮 。 


.Deployment: 用 于 管理 无 状态 的 持久 化 应 用 ， 例 如 HTTP 服 务 
性 ; 它 用 于 为 Pod 和 ReplicaSet 提 供 声明 式 更 新 ， 是 建构 在 ReplicaSet 之 
上 的 更 为 高 级 的 控制 器 。 


'StatefulSet: 用 于 管理 有 状态 的 持久 化 应 用 ， 如 database 服 务 程 
序 ; 其 与 Deployment 的 不 同 之 处 在 于 StatefulSet 会 多 每 和 Pod 创建 一 个 
独 有 的 持久 性 标识 符 ， 并 会 确保 各 Pod 之 间 的 顺序 性 


.DaemonSet: 用 于 确保 每 个 点 都 运行 了 某 Pod 的 一 个 副本 ， 新 增 
的 节点 一 样 会 被 添加 此 类 Pod; 在 节点 移 除 时 ， 此 类 Pod 会 被 回收 ; 
DaemonSet 常 用 于 运行 集群 存储 守护 进程 一 如 glusterd 和 ceph， 还 有 日 
志 收 集 进程 一 如 fluentd 和 ]ogstash， 以 及 监控 进程 一 如 Prometheus 的 
Node Exporter 、 collectd、Datadog agent 和 Ganglia 的 gmond 等 。 


.Job: 用 于 管理 运行 完成 后 即 可 终止 的 应 用 ， 例 如 批 处 理 作 业 任 
务 ; 换 句 话 讲 ，Job 创 建 一 个 或 多 个 Pod， 并 确保 其 符合 目标 数量 ， 和 直 
到 Pod 正 党 结束 而 终止 。 


(2) 发 现 和 负载 均衡 


Pod 资 源 可 能 会 因为 任何 意外 故障 而 被 重建 ， 于 是 它 需 要 固定 的 
可 被 发现 ”的 方式 。 另 外 ，Pod 资 源 仅 在 集群 内 可 见 ， 它 的 客户 端 也 可 
能 是 集群 内 的 其 他 Pod 资 源 ， 知 要 开放 双 合 外 部 网 络 中 的 用 户 访问 ， 则 
需要 事先 将 其 术 露 到 集群 外 部 | 并 且 要 为 同一 种 工作 负载 的 访问 流量 
进行 负载 均衡 。Kubernetes 使 用 标准 的 资源 对 象 来 解决 此 类 问题 ， 它 
们 是 用 于 为 工作 负载 添加 发 现 机 制 及 负载 均衡 功 外 E 的 Service 资 务 涛 和 
， 以 及 通过 七 层 代理 实现 请 求 流量 负载 均衡 的 Ingress 资 
源 。 


(3) 配置 与 存储 


Docker 容 如 分 层 联合 挂 载 的 方式 决定 了 不 宜 在 容器 内 部 存储 需要 
持久 化 的 数据 ， 于 是 它 通 过 引入 挂 载 外 部 存储 卷 的 方式 来 解决 此 类 问 
题 ， 而 Kubernetes 则 为 此 设计 了 Volume 资 源 ， 它 支持 众多 类 型 的 存储 
设备 或 存储 系统 ， 如 GlusterFS、CEPH RBD 和 Flocker 等 。 另 外 ， 新 版 
本 的 Kubermetes 还 支持 通过 标准 的 CSI (Container Storage Interface) 统 
一 存储 接口 以 及 扩展 支持 更 多 类 型 的 存储 系统 。 


另外， 基于 镜像 构建 容 颖 应 用 时 ， 其 配置 信息 于 镜像 制作 时 焙 
入， 从 而 为 不 同 的 环境 定制 配置 就 变 得 较为 困难 。Docker 使 用 环境 变 
量 等 作为 解决 方案 ,但 这 么 一 来 束 得 于 容 右 局 动 时 将 值 传 入 ， 且 无 法 
在 运行 时 修改 。ConfigMap 资 源 能 够 以 环境 变量 或 存储 卷 的 方式 接 入 


到 Pod 资 源 的 容器 中 ， 并 且 可 被 多 个 同类 的 Pod 共 至 引用 ， 从 而 实 
现 “ 一 次 修改 ， 多 处 生效 ”。 不 过 ， 这 种 方式 不 适 于 存储 敏感 数据 ， 如 
私 铀 、 密 码 等 ， 那 是 另 一 个 资产 类 型 Secret 的 功能 。 


(4) 集群 级 资源 
Pod、Deployment、Service 和 ConfigMap 等 资源 属于 名 称 空 间 级 
别 ， 可 由 相应 的 项 目 管理 员 所 管理 。 然 而 ，Kubernetes 还 存在 一 些 集 
群 级 别 的 资源 ， 用 于 定义 集群 目 身 配置 信息 的 对 象 ， 它 们 仅 应 该 由 集 
群 管理 员 进 行 操作 。 集 群 级 资源 主要 包含 以 下 几 种 类 型 。 


.Namespace: 资源 对 象 名 称 的 作用 范围 ， 绝 大 多 数 对 象 都 隶属 于 
某 个 名 称 空间 ， 默 认 时 隶属 于 “default”。 


.Node: Kubernetes 集 群 的 工作 节点 ， 其 标识 符 在 当前 集群 中 必须 
是 唯 一 的 。 
pi 


.Role: 名 称 空间 级 别 的 由 规则 组 成 的 权限 集合 ， 可 被 RoleBinding 


引用 


ClusterRole: Cluster 级 别 的 由 规则 组 成 的 权限 集合 ， 可 被 
RoleBinding 和 ClusterRoleBinding 引 用 。 


.RoleBinding: 将 Role 中 的 许可 权限 绑 定 在 一 个 或 一 组 用 户 之 上 ， 
它 隶 属于 且 仅 能 作用 于 一 个 名 称 空 间 ; 绑 定 时 ， 可 以 引用 同一 名 称 空 
间 中 的 Role， 也 可 以 引用 全 局 名 称 空 间 中 的 ClusterRole 。 


ClusterRoleBinding: 将 ClusterRole 中 定义 的 许可 权限 绑 定 在 一 个 
或 一 组 用 户 之 上 ; 它 能 够 引用 全 局 名 称 空间 中 的 ClusterRole， 并 能 通 
过 Subject 答 加 相关 信息 。 


(5) 元 数据 型 资源 


此 类 资源 对 象 用 于 为 集群 内 部 的 其 他 资源 配置 其 行为 或 特性 ， 如 
HorizontalPodAutoscaler 资 源 可 用 于 上 自动 伸缩 工作 负载 类 型 的 资源 对 象 
的 规模 ，Pod 模 板 资 源 可 用 于 为 pod 资 源 的 创建 预制 模板 ， 而 
ee 可 为 名 称 空间 的 资源 设置 其 CPU 和 内 存 等 系统 级 资源 的 
数量 限制 等 。 


名 提示 ”一 个 应 用 通常 第 要 多 个 资源 的 支撑 ， 例 如 ， 使 用 
Deployment 资 源 管理 应 用 实例 (Pod) 、 使 用 ConfigMap 资 源 保存 应 用 
se Service 或 Ingress 资 源 骏 露 服务 、 使 用 Volume 资 源 提供 外 部 
子 储 等 。 


本 书后 面 篇 幅 的 主体 部 分 就 展开 介绍 这 些 资源 类 型 ， 它 们 是 将 容 
器 化 应 用 托管 运行 于 Kubernetes 集 群 的 重要 工具 组 件 。 


3.1.2 ”资源 及 其 在 API 中 的 组 织 形式 


在 Kubermetes 上， 资源 对 象 代表 了 系统 上 的 持久 类 实体 ， 
Kubermetes 用 这 些 持 久 类 实体 来 表达 集群 的 状态 ， 包 括 容 妮 化 的 应 用 
程序 正 运 行 于 哪些 和 点， 每 个 应 用 程序 有 哪些 资源 可 用 ， 以 及 每 个 应 
用 程序 各 上 自 的 行为 抹 略 ， 如 重启 、 升 级 及 容错 案 略 等 。 一 个 对 象 可 能 
会 包含 多 个 资源 ， 用 户 可 对 这 些 资 源 执 行 增 、 删 、 改 、 查 等 管理 操 
作 。Kubernetes 通 稼 利用 标准 的 RESTful 术 语 来 描述 API 概 念 。 


资源 类 型 (resource type) 是 指 在 URL 中 使 用 的 名 称 ， 如 Pod、 
Namespace 和 Service 等 ， 其 URL 格 式 


为 “GROUP/VERSION/RESOURCE”， 如 apps/vl/deployment 。 


.所 有 资源 类 型 都 有 一 个 对 应 的 JSON 表 示 格 式 ， 称 为 “种 
类 ” (kind) ; 客户 端 创建 对 象 必 须 以 JSON 提 交 对 和 象 的 配置 信息 。 


.隶属 于 同一 种 资源 类 型 的 对 象 组 成 的 列表 称 为 “ 集 
” (collection) ， 如 PodList 。 


. 某 种 类 型 的 单个 实例 称 为 “资源 ” (resource) 或 “对 
象 ”(object) ， 如 名 为 pod-demo 的 Pod 对 象 。 


kind 代 表 着 资源 对 象 所 属 的 类 型 ， 如 Namespace、Deployment 、 
Service 及 Pod 等 ， 而 这 些 资 源 类 型 大 体 又 可 以 分 为 三 个 类 别 ， 具 体 如 
下 。 


n> 


“对象 (Object) 类 : 对 象 表示 Kubernetes 系 统 上 的 持久 化 实体 ， 一 
个 对 象 可 能 包含 多 个 资源 ， 客 户 端 可 用 它 执 行 多 种 操作 。 
Namespace、Deployment、Service 及 Pod 等 都 属于 这 个 类 别 。 


:列表 (List) 类 : 列表 通常 是 指 同一 类 型 资源 的 集合 ， 如 
PodLists、NodeLists 等 。 


简单 (Simple) 类 : 常用 于 在 对 象 上 执行 某 种 特殊 操作 ， 或 者 管 
理 非 持久 化 的 实体 ， 如 /binding 或 /status 等 。 


Kubernetes 绝 大 多 数 的 API 资 源 类 型 都 是 “对 象 "， 它 们 代表 着 集群 
中 某 个 概念 的 实例 。 有 一 小 部 分 的 API 资 源 类 型 为 “虚拟 ” (virtual) 类 
型 ， 它 们 用 于 表达 一 类 “操作 ” (operation) 。 所 有 的 对 象 型 资源 都 拥 
有 一 个 独 有 的 名 称 标识 以 实现 其 需 等 的 创建 及 获取 操作 ， 不 过 ， 虚 拟 
型 资源 无 须 获 取 或 不 依赖 于 贿 等 性 时 也 可 以 不 使 用 专用 标识 符 。 


有 些 资源 类 型 隶属 于 集群 范畴 ， 如 Namespace 和 
PersistentVolume， 而 多 数 资源 类 型 则 受 限 于 名 称 空 间 ， 如 Pod、 
Deployment 和 Service 等 。 名 称 空 间 级 别 的 资源 的 UREL 路 径 中 含有 其 所 
属 空间 的 名 称 ， 这 些 资源 对 象 在 名 称 空间 被 删除 时 会 被 一 并 删除 ， 并 
县 这 邱 资源 对 象 的 访问 也 将 受 探 于 其 所 属 的 名 称 空间 级 别 的 授权 审 
本 


Kubernetes 将 API 分 割 为 多 个 逻辑 组 合 ， 称 为 API 群 组 ， 它 们 文 持 
单独 启用 或 禁用 ， 并 能 够 再 次 分 解 。API Server 支 持 在 不 同 的 群 组 中 使 
用 不 同 的 版 本 ， 人 允许 各 组 以 不 同 的 速度 演进 ， 而 且 也 文 持 同 一 群 组 同 
时 存在 不 同 的 版 本 ， 如 apps/v1、apps/vlbeta2 和 apps/vlbeta1， 也 因此 
能 够 在 不 同 的 群 组 中 使 用 同名 的 资源 类 型 ， 从 而 能 在 稳定 版 本 的 群 组 
及 新 的 实验 群 组 中 以 不 同 的 特性 同时 使 用 同一 个 资源 类 型 。 群 组 化 管 
理 的 API 使 得 其 可 以 更 轻松 地 进行 扩展 。 当 前 系统 的 API Server 上 的 相 
关 信 息 可 通过 “kubectl api-versions” 命 令 获 取 。 命 令 结果 中 显示 的 不 少 
API 群 组 在 后 续 的 章节 中 配置 资源 清单 时 会 多 次 用 到 : 


[root@master ~]# kubect1l api-versions 
admissionregistration.k8s.io/vibetali 
apiextensions.k8s.io/vibetai 
apiregistration.k8s.io/vi 
apiregistration.k8s.io/vibeta1 
apps/vi1 

apps/vibetal1 

apps/vibeta2 
authentication.k8s.io/v1 
authentication.k8s.io/vibetal1 
authorization.k8s.io/vi 
authorization.k8s.io/vibetai 
autoscaling/v1i 
autoscaling/v2betal 

batch/vi 

batch/vibeta1i 
certificates.k8s.io/vibetal 
events.k8s.io/vibetal 
extensions/vibetal 
networking.k8s.io/vi 
policy/vibetal 
rbac.authorization.k8s.io/vi 
rbac.authorization.k8s.io/vibetal 


scheduling.k8s.io/vibetal 
storage.k8s.io/vi1 
storage.k8s.io/vibetal 

v1 


Kubernetes 的 API 以 层级 结构 组 织 在 一 起 ， 每 个 API 群 组 表现 为 一 
个 以 wapis" 为 根 路 径 的 REST 路 径 ， 不 过 核心 群 组 core 有 一 个 专用 的 人 简 
化 路 径 %api/v1”。 目 前 ， 第 用 的 API 群 组 可 归 为 如 下 两 类 。 


.核心 群 组 (core group) : REST 路 径 为 /apiv1， 在 资源 的 配置 信 
妃 apiVersion 字 段 中 引用 时 可 以 不 指定 路 径 ， 而 仅 给 出 版 本 ， 


如 “apiVersion: V1”。 


.命名 的 群 组 (named group) : REST 路 径 
为 /apis/$GROUP_NAME/$VERSION， 例 如 /apis/apps/V1， 它 在 
apiVersion 字 段 中 引用 的 格式 为 “apiVersion: 
$GROUP_NAME/$VERSION”, 如 “apiVersion: apps/v1”。 


总 结 起 来 ， 名 称 空间 级 别 的 每 一 个 资源 类 型 在 API 中 的 URL 路 径 
表示 都 可 简单 抽象 为 形 
U0“/apis/<group>/<version>/namespaces/<namespace>/<kind-plural>” 的 
路 径 ， 如 default 名 称 空间 中 Deployment 类 型 的 路 径 
为 /apis/apps/V1/namespaces/default/deployments， 通 过 此 路 径 可 获取 到 
default 名 称 空 间 中 所 有 Deployment 对 和 象 的 列表 : 


~]$ kubectl1 get --raw /apis/apps/vi/namespaces/default/deployments | jdq ， 


"kind": "DeploymentList", 
"apiVversion":; "apps/vi1", 


另外 ，Kubernetes 还 文 持 用 户 目 定 义 资源 类 型 ， 目 前 常用 的 方式 
有 三 种 : 一 是 修改 Kubernetes 源 代码 目 定 义 类 型 ， 二 是 创建 一 个 目 定 
义 的 API Server， 并 将 其 聚合 至 集群 中 ; 三 是 使 用 目 定 义 资 源 
(Custom Resource Definition, CRD) 。 


3.1.3 ”访问 Kubernetes REST API 


以 编程 的 方式 访问 Kubernetes REST API 有 助 于 了 解 其 流 式 化 的 集 
群 管理 机 制 ， 一 种 常用 的 方式 是 使 用 curl 作 为 HTTP 客 户 端 直接 通过 
API Server 在 集群 上 操作 资源 对 象 模拟 请 求 和 啊 应 的 过 程 。 不 过 ， 由 
kubeadm 部 署 的 Kubernetes 集 群 默认 仪 支持 HTTPS 的 访问 接口 ， 它 需 进 
行 一 系列 的 认证 检查 ， 好 在 用 户 也 可 以 借助 kubectl proxy 命 令 在 本 地 主 
机 上 为 API Server 启 动 一 个 代理 网 关 ， 由 它 支 持 使 用 HTTP 进 行 通 信 ， 
其 工作 逻辑 如 图 3-3 所 示 。 


kubectl 
proxy 


apiserver 


3-3 ”kubectl 在 本 地 代理 API Server 
例如 ， 于 本 地 127.0.0.1 的 8080 端 口上 启动 API Server 的 一 个 代理 网 
关 : 


~]$ kubect1 proxy --port=8080 
Starting to serve on 127.0.0.1:8080 


而 后 即 可 于 另 一 终端 使 用 cu 一 类 的 客户 端 工具 对 此 套 接 字 地 址 
发 起 访问 请 求 ， 例 如 ， 请 求 Kubernetes 集 群 上 的 NamespaceList 资 源 对 
象 ， 即 列 出 集群 上 所 有 的 Namespace 对 象 : 


~]$ curl localhost:8080/api/vi/namespaces/ 
{ 


"kind": "NamespaceList", 
"apiVersion™; "vi1", 


或 者 使 用 JSON 的 命令 行 处 理 右 jg 命令 对 响应 的 JSON 数 据 流 进行 
内 容 过 滤 ， 例 如 ， 下 面 的 命令 仅 用 于 显示 相关 的 NamespaceList 对 象 中 
的 各 成 员 对 象 : 


~]$ curl -s localhost:8080/api/vi/namespaces/ | jd .items[].metadata.name 
"default" 

"kube-public" 

"kube-system" 


给 出 特定 的 Namespace 资 源 对 象 的 名 称 则 能 够 直接 获取 相应 的 资 
源 信 息 ， 以 kube-system 和 名称 空间 为 例 : 


~]$ curl -s localhost:8080/api/vi/namespaces/kube-system 
{ 


"kind": "Namespace", 
"apiVersion™"; "vi1", 
"metadata": { 
"name": "kube-system", 
"selfLink": "/api/vi/namespaces/kube-system", 
"uid": "eb6bf659-9d0e-11e8-bfoOd-000c29abof5b", 
"resourceVersion": "33", 
"creationTimestamp": "2018-08-11T02:33:232Z" 
}, 
"spec" D { 
"finalizers": [ 
"kubernetes" 


] 


了 
"status": 
"phase": "Active" 


上 述 命 令 啊 应 的 结果 中 展现 了 Kubernetes 大 多 数 资 源 对 象 的 资源 
配置 格式 ， 它 是 一 个 JSON 序 列 化 的 数据 结构 ， 具 有 kind 、apiVersion 、 
metadata、spec 和 status 五 个 一 级 字段 ， 各 字段 的 意义 和 功能 将 在 3.2 广 
中 重点 介绍 。 


3.2 ”对 象 类 资源 格式 


Kubernetes API 仪 接受 及 响应 JSON 格 式 的 数据 (JSON 对 象 ) ， 同 
上 时， 为 了 便于 使 用 ， 它 也 允许 用 户 提供 YAML 格 式 的 POST 对 象 ， 但 
API Server 需 要 事先 自行 将 其 转换 为 JSON 格 式 后 方 能 提交 。API Server 
接受 和 返回 的 所 有 JSON 对 和 象 都 遵循 同一 个 模式 ， 它 们 都 具有 kind 和 
0 用 于 标识 对 象 所 属 的 资源 类 型 、API 群 组 及 相关 的 版 


进一步 地 ， 大 多 数 的 对 象 或 列表 类 型 的 资源 还 需要 具有 三 个 藤 套 
型 的 字段 metadata、spec 和 status。 其 中 metadata 字 段 为 资源 提供 元 数据 
信息 ， 如 名 称 、 隶 属 的 名 称 空 间 和 标签 等 ;spec 则 用 于 定义 用 户 期 望 
的 状态 ， 不 同 的 资源 类 型 ， 其 状态 的 意义 也 各 有 不 同 ， 例 如 Pod 资 源 
最 为 核心 的 功能 在 于 运行 容 絮 ;， 而 status 则 记录 着 活动 对 象 的 当前 状态 
信息 ， 它 由 Kubernetes 系 统 目 行 维 护 ， 对 用 户 来 说 为 只 读 字段 。 


每 个 资源 通常 仅 接 受 并 返回 单一 类 型 的 数据 ， 而 一 种 类 型 可 以 被 
多 个 反映 特定 用 例 的 资源 所 接受 或 返回 。 例 如 对 于 Pod 类 型 的 资源 来 
说 ， 用 户 可 创建 、 更 新 或 删除 Pod 对 象 ， 然 而 ， 每 个 Pod 对 象 的 
metadata、spec 和 status 字 上 段 的 值 却 又 是 各 目 独 立 的 对 象 型 数据 ， 它 们 
可 被 单独 操作 ， 尤 其 是 status 对 象 ， 是 由 Kubernetes 系 统 单独 进行 目 动 
更 新 ， 而 不 能 由 用 户 手 动 操作 它 。 


3.2.1 ”资源 配置 清早 


3.1 节 中 曾 使 用 curl 命 令 通 过 代理 的 方式 于 API Server 上 请 求 到 了 
kube-system 这 个 Namespace 活 动 对 象 的 状态 信息 ， 事 实 上 ， 用 户 也 可 
以 直接 使 用 “kubectl get TYPE/NAME-o yam 凡 命令 获取 任何 一 个 对 象 的 
YAML 格 式 的 配置 清单 ， 或 者 使 用 “kubectl get TYPE/NAME-o json” 命 
令 获 取 JSON 格 式 的 配置 清单 。 例 如 ， 可 使 用 下 面 的 命令 获取 kube- 
system 的 状态 : 


~]$ kubectl1 get namespace kube-system -0 yaml 
apiVersion: v1 
kind: Namespace 
metadata: 
creationTimestamp: 2018-08-11T02:33:23Z 
name: kube-system 
resourceVersion: "33" 
selfLink: /api/vi/namespaces/kube-system 
uid: eb6bf659-9doe-11e8-bfod-000c29abof5b 
spec: 
finalizers: 
- kubernetes 
status: 
phase: Active 


除了 极 少数 的 资源 之 外 ，Kubermnetes 系 统 上 的 绝 大 多 数 资 源 都 是 
由 其 使 用 者 所 创建 的 。 创 建 时 ， 需 要 以 与 上 壕 输 出 结果 中 类 似 的 方式 
以 YAML 或 JSON 序 列 化 方案 定义 资源 的 相关 配置 数据 ， 即 用 户 期 望 的 
目标 状态 ， 而 后 再 由 Kubernetes 的 底层 组 件 确 保 活 动 对 象 的 运行 时 状 
态 与 用 户 提供 的 配置 清单 中 定义 的 状态 无 限 接 近 。 因 此 ， 资 源 的 创建 
要 通过 用 户 提 供 的 资源 配置 清单 来 进行 ， 其 格式 类 似 于 kubectl get 命 令 
获取 到 的 YAML 或 JSON 形 式 的 输出 结果 。 不 过 ，status 字 段 对 用 户 来 说 
为 只 读 字 段 ， 它 由 Kubemetes 集 群 自动 维护 。 例 如 ， 下 面 就 是 一 个 创 
J 源 时 提供 的 资源 配置 清单 示例 ， 它 仅 提供 了 几 个 必要 

J 地 的 


apiVersion: v1 
kind: Namespace 
metadata: 

name: dev 
spec: 

finalizers: 

- kubernetes 


将 如 上 所 述 配 置 清单 中 的 内 容 保存 于 文件 中 ， 使 用 "kubectl create- 
f/PATH/TO/FILE” 命 令 即 可 将 其 创建 到 集群 中 。 创 建 完 成 后 查看 其 
YAML 或 JSON 格 式 的 输出 结果 ， 可 以 看 到 Kubernetes 会 补 全 其 大 部 分 
的 字段 ， 并 提供 相应 的 数据 。 事 实 上 ，Kubernetes 的 大 多 数 资源 都 能 
够 以 类 似 的 方式 进行 创建 和 查看 ， 而 且 它 们 几乎 都 遵循 类 似 的 组 织 结 
构 ， 下 面 的 命令 显示 了 第 2 章 中 使 用 kubectl run 命 令 创 建 的 Deployment 
资源 对 象 myapp 的 状态 信息 : 


~]$ kubectl1 get deployment myapp -0 yaml 
apiVersion: extensions/vibeta1 
kind: Deployment 
metadata: 
name: myapp 
ec: 
replicas: 3 
selector: 

matchLabels: 

run: myapp 


为 了 玫 约 篇 幅 ， 上 面 的 输出 结果 省 去 了 大 部 分 内 容 ， 仅 保留 了 其 
主体 结构 。 从 命令 结果 可 以 看 出 ， 它 也 遵循 Kubernetes API 标 准 的 资源 
组 织 格式 ， 由 apiVersion、kind、metadata、spec 和 status 五 个 核心 字段 
组 成 ， 只 是 spec 字 7 段 中 骸 套 的 内 容 与 Namespace 资 源 几 乎 完全 不 同 。 


事实 上 ， 对 几乎 所 有 的 资源 来 说 ，apiVersion、kind 和 metadata 字 
段 的 功能 基本 上 都 是 相同 的 ， 但 spec 则 用 于 资源 的 期 望 状态 ， 而 资源 
之 所 以 存在 类 型 上 的 不 同 ， 也 在 于 它们 的 岁 套 属性 存在 显著 差别 ， 它 
由 用 户 定 义 和 维 护 。 而 status 字 段 则 用 于 记录 活动 对 象 的 当前 状态 ， 它 
， 或 者 正 处 于 转换 为 与 其 相同 
Yl 0 


3.2.2 ”metadata 册 套 字 上 段 


”metadata 守 段 用 于 描述 对 象 的 属性 信息 ， 其 内 构 多 个 字段 用 于 害 
义 资源 的 元 数据 ， 例 如 name 和 1labels 等 ， 这 些 字段 大 体 可 分 为 必要 字段 
和 可 选 字段 两 大 类 。 和 名称 空 间 级 别 的 资产 的 必 选 字段 包括 如 下 三 项 。 


namespace: 指定 当前 对 象 隶属 的 名 称 空间 ， 默 认 值 为 default 。 


mame: 设 定 当前 对 象 的 名 称 ， 在 其 所 属 的 名 称 空间 的 同一 类 型 中 
必须 唯一 。 

-uid， 当前 对 象 的 唯一 标识 符 ， 其 唯一 性 仅 发 生 在 特定 的 时 间 段 和 
名 称 空间 中 ;此 标识 符 主要 是 用 于 区 别 拥有 同样 名 字 的 “已 删除 "和 * 重 
新 创建 "的 同一 个 名 称 的 对 象 。 


可 选 字 段 通 销 是 指 由 Kubernetes 系 统 目 行 维护 和 设置 ， 或 者 存在 
默认 ， 或 者 本 号 允许 使 用 空 值 等 类 型 的 字段 ， 和 常用 的 有 如 下 几 个 : 

-labels: 设 定 用 于 标识 当前 对 象 的 标签 ， 键 值 数 据 ， 常 被 用 作 挑 
选 条 件 。 

-annotations: 非 标识 型 键 值 数据 ， 用 来 作为 挑选 条 件 ， 用 于 labels 
的 补充 。 

TesourceVersion: 当前 对 象 的 内 部 版 本 标识 符 ， 用 于 让 客户 端 确 
定 对 象 变 动 与 否 。 

"generation: 用 于 标识 当前 对 象 目 标 状态 的 代 别 。 

:creationTimestamp: 当前 对 象 创建 日 期 的 时 间 惟 。 

.deletionTimestamp: 当前 对 象 删 除 日 期 的 时 间 惟 。 


此 外 ， 用 户 通过 配置 清单 创建 货 源 时 ， 通 单 仅 需要 给 出 必 选 字 
段 ， 可 选 字段 可 按 需 指定 ， 对 于 用 户 未 明确 定义 的 藤 套 字段 ， 则 需要 
由 一 系列 的 finalizer 组 件 目 动 予 以 填充 。 而 用 户 需 要 对 资源 创建 的 目标 
资源 对 象 进行 强制 校 验 ， 或 者 在 修改 时 需要 用 到 initializer 组 件 完成 ， 


例如 ， 为 每 个 待 创建 的 Pod 对 象 添加 一 个 Sidecar 容 器 等 。 不 同 的 资源 
类 型 也 会 存在 一 些 专 有 的 抽 套 字段 ， 例 如 ，ConfigMap 资 源 还 支持 使 


用 clusterName 等 。 


3.2.3 ”spec 和 status 字 段 


Kubernetes 用 spec 来 描述 所 期 望 的 对 象 应 该 具有 的 状态 ， 而 用 
status 字 段 来 记录 对 象 在 系统 上 的 当前 状态 ， 因 此 status 字 段 仅 对 活动 
对 象 才 有 意义 。 这 两 个 字段 都 属于 般 套 类 型 的 字段 。 在 定义 资源 配置 
清单 时 ，spec 是 必须 定义 的 字段 ， 用 于 描述 对 象 的 目标 状态 ， 即 用 户 
期 望 对 象 需要 表现 出 来 的 特征 。status 字 段 则 记录 了 对 象 的 当前 状态 

(或 实际 状态 ) ， 此 字段 值 由 Kubernetes 系 统 负责 填充 或 更 新 ， 用 户 
不 能 手动 进行 定义 。 Master 的 controller-manager 通 过 相应 的 控制 器 组 件 
动态 管理 并 确保 对 象 的 实际 状态 匹配 用 户 所 期 望 的 状态 ， 它 是 一 种 调 
和 (reconciliation) 配置 系统 。 


例如 ，Deployment 有 是 一 种 用 于 描述 集群 中 运行 的 应 用 的 对 象 ， 
此 ， 创 建 Deployment 类 型 的 对 象 时 ， 需 要 为 目标 Deployment 对 和 象 设 定 
spec， 指 定期 望 需要 运行 的 Pod 副 本 数量 、 使 用 的 标签 选择 名 以 及 Pod 
模板 等 。Kubernetes 系 统 读 取 行 创建 的 Deployment 对 象 的 spec 以 及 系统 
上 相应 的 活动 对 象 的 当前 状态 ， 必 要 时 进行 对 象 更 新 以 确 你 status 字 段 
吻合 spec 字 段 中 期 望 的 状态 。 如 果 这 其 中 任 一 实例 出 现 问题 (status 字 
段 值 发 生 了 变化 ) ， 那 么 Kubernetes 系 统 则 需要 及 时 对 spec 和 status 字 
段 的 差异 做 出 啊 应 ， 例 如 ， 补 足 缺 失 的 Pod 副 本 数目 等 。 


spec 字 上 段 敬 套 的 字段 对 于 不 同 的 对 象 类 型 来 说 各 不 相同 ， 具 体 需 
要 参照 Kubernetes API 参 考 手 册 中 的 说 明 分 别 进行 获取 ， 核 心 资源 对 象 
的 常用 配置 字段 将 会 在 本 书后 面 的 章节 中 进行 讲解 。 


3.2.4 换 源 配置 请 单 格 式 文 档 


定义 资源 配置 清单 时 ， 尽 管 apiVersion、kind 和 metadata 有 章 可 
循 ， 但 spec 字 段 对 不 同 的 资源 来 说 却 是 千差万别 的 ， 因 此 用 户 需 要 参 
考 Kubernetes API 的 参考 文档 来 了 解 各 种 可 用 属性 字段 。 好 在 ， 
Kubemetes 在 系统 上 内 建 了 相关 的 文档 ， 用 户 可 以 使 用 “kubectl 
explain” 命 令 直 接 获 取 相 关 的 使 用 帮助 ， 它 将 根据 给 出 的 对 象 类 型 或 相 
应 的 租 套 字段 来 显示 相关 的 下 一 级 文档 。 例 如 ， 要 了 解 Pod 资 源 的 一 
级 字段 ， 可 以 使 用 类 似 如 下 的 命令 ， 命 令 结果 会 输出 文 持 使 用 的 各 一 
组 字段 及 其 说 明 : 


~]$kubect1 explain pods 


需要 了 解 茶 一 级 字段 表示 的 对 象 之 下 的 二 级 对 象 字 段 时 ， 只 需要 
指定 其 一 级 字段 的 对 象 名 称 即 可 ， 三 级 和 四 级 字段 对 象 等 的 查看 方式 
依 此 类 推 。 例 如 查看 Pod 资 源 的 Spec 对 象 文 持 租 套 使 用 的 二 级 字段 ， 可 
使 用 类 似 如 下 的 命令 : 


~]$ kubect1 explain pods.spec 
RESOURCE: spec <0bject> 


DESCRIPTION: 
Specification of the desired behavior of the pod. ..... 


PodSpec is a description of a pod. 


FIELDS : 

activeDeadlineSeconds <integer> 
Optional duration in seconds the pod may be active on the node relative to 
StartTime before the system will actively try to mark it failed and kill 
associated containers. Value must be a positive integer. 

containers <[]JObject> -required- 
List of containers belonging to the pod. Containers cannot currently be 
added or removed. There must be at least one container in a Pod. Cannot 

be updated. 


对 象 的 spec 字 段 的 文档 通常 包含 RESOURCE、DESCRIPTION 和 
FIELDS 儿 入 ， 其 中 FIELDS 市 中 给 出 了 可 构 套 使 用 的 了 字段、 数据 类 型 
及 功能 描述 。 人 例如， 上面 命 令 的 结果 显示 在 FIELDS 中 的 containers 字 段 


的 数据 类 型 是 一 个 对 象 列表 〈[]Object) ， 而 且 是 一 个 必 选 字段 。 任 何 
值 为 对 象 类 型 数据 的 字段 都 会 供 套 一 到 多 个 下 一 级 字段 ， 例 如 ，Pod 

对 象 中 的 每 个 容器 也 十 对 象 类 型 数据 ， 它 同样 包含 肃 套 字段 ， 但 容器 
不 支持 单独 创建 ， 而 是 要 包含 于 Pod 对 象 的 上 下 文中 ， 其 详细 信息 可 

通过 三 级 字段 来 获取 ， 命 令 及 其 结 采 示例 如 下 : 


~]$ kubect1 explain pods,spec.containers 
RESOURCE: containers <[]0object> 


DESCRIPTION: 

List of containers belonging to the pod. Containers cannot currently be 
added 
or removed. There must be at least one container in a Pod. Cannot be updated. 


A single application container that you want to run within a pod. 


FIELDS : 
args <[]string> 
Arguments to the entrypoint,. The docker image's CMD is used if this is not 
provided. ...... 


command <[]string> 
Entrypoint array. Not executed within a shell. The docker image's 
ENTRYPOINT is used if this is not provided. ..... 


env <[]jobject> 
List of environment variables to set in the container. Cannot be updated. 


内 建文 档 大 大 降低 了 用 户 手 动 创建 资源 配置 清单 的 难度 ， 壬 试 使 
用 某 个 资源 类 型 时 ，explain 也 的 确 是 用 户 的 常用 命令 之 一 。 熟 悉 各 常 
用 字段 的 功用 之 后 ， 以 同类 型 的 现 有 活动 对 象 的 清单 为 模板 可 以 更 快 
地 生成 目标 资源 的 配置 文件 ， 命 令 格式 为 "kubectl get TYPE NAME-o 
yaml--export"， 其 中 --export 选 项 用 于 省 略 输 出 由 系统 生成 的 信息 。 例 
如 ， 基 于 现在 的 Deployment 资 源 对 象 myapp 生 成 配置 模板 deploy- 
demo.yaml 文 件 ， 可 以 使 用 如 下 命令 : 


~]$ kubectl1 get deployment myapp -0 yaml --export > deploy-demo.yaml 


通过 资源 清单 文件 管理 资源 对 象 较 之 直接 通过 命令 行进 行 操作 有 
着 诸多 优势 ， 具 体 包括 命令 行 的 操作 方式 仅 支 持 部 分 资源 对 象 的 部 分 
属性 ， 而 资源 清单 文 持 配置 资源 的 所 有 属性 字段 ， 而 且 使 用 配置 清单 


文件 还 能 够 进行 版 本 人 退路、 复审 等 高 级 功能 的 操作 。 本 书后 续 革 市 中 
的 大 部 分 资源 管理 操作 都 会 借助 于 资源 配置 文件 进行 。 


3.2.5 “资源 对 象 管理 方式 


Kubernetes 的 API Server 遵 循 声明 式 编程 (declarative 
programming) 范式 而 设计 ， 侧 重 于 构建 程序 程序 逻辑 而 无 须 用 户 描述 
其 实现 流程 ， 用 户 只 需要 设 定 期 望 的 状态 ， 系 统 即 能 上 自行 确定 需要 执 
行 的 操作 以 确保 达到 用 户 期 望 的 状态 。 例 如 ， 期 望 某 Deployment 控 制 
句 管 理 三 个 Pod 资 源 对 象 时 ， 而 系统 观察 到 的 当前 数量 却 是 两 个 ， 于 是 
系统 就 会 知道 需要 创建 一 个 新 的 Pod 资 源 来 满足 此 期 望 。Kubermetes 的 
自 愈 、 上 自治 等 功能 都 依赖 于 其 声明 式 机 制 。 


与 此 对 应 的 另 一 种 范式 称 为 陈述 式 编程 (imperative 
programming) ， 代 码 侧重 于 通过 创建 一 种 告诉 计算 机 如 何 执行 操作 的 
算法 来 更 改 程序 状态 的 语句 来 完成 ， 它 与 硬件 的 工作 方式 密切 相关 ， 
通常 ， 代 码 将 使 用 条 件 语句 、 循 环 和 类 继承 等 控制 结构 。 为 了 便于 用 
户 使 用 ，Kubernetes 的 API Server 也 文 持 陈 述 式 苑 式 ， 它 直接 通过 命令 
及 其 选项 完成 对 象 的 管理 操作 ， 前 面 用 到 的 run、expose、delete 和 get 等 
命令 都 属于 此 类 ， 执 行 时 用 户 需 要 告诉 系统 要 做 什么 例如， 使 用 run 
命令 创建 一 个 有 着 3 个 Pod 对 象 副本 的 Deployment 对 象 ， 或 者 通过 delete 
命令 删除 一 个 名 为 myapp 的 Service 对 象 。 


Kubernetes 系 统 的 大 部 分 API 对 象 都 有 着 spec 和 status 两 个 字段 ， 其 
中 ，spec 用 于 让 用 户 定 义 所 期 望 的 状态 ， 系 统 从 中 读 出 相关 的 定义 ; 而 
status 则 是 系统 观察 并 人 负责 写 入 的 当前 状态 ， 用 户 可 以 从 中 获取 相关 的 
信息 。Kubernetes 系 统 通 过 控制 器 监控 着 系统 对 象 ， 由 其 负责 让 系统 当 
前 的 状态 无 限 接 近 用 户 所 期 望 的 状态 。 


kubect 的 命令 由 此 可 以 分 为 三 类 : 陈述 式 命令 (imperative 

command) 、 陈 述 式 对 象 配置 (imperative object configuration) 和 声明 
式 对 象 配 置 (declarative object configuration) 。 第 一 种 方式 即 此 前 用 到 
的 run、expose、delete 和 get 等 命令 ， 它 们 直接 作用 于 Kubernetes 系 统 上 
的 活动 对 象 ， 简 单 易 用 ， 但 不 文 持 代 码 复 用 、 修 改 复审 及 审计 日 志 等 
功能 ， 这 些 功能 的 使 用 通常 要 依赖 于 资源 配置 文件 ， 这 些 文件 也 称 为 
资源 清单 。 在 这 种 模式 下 ， 用 户 可 以 访问 每 个 对 象 的 完整 模式 ， 但 用 
户 还 需要 深入 学 习 Kubernetes API。 


如 3.2.4 节 所 述 ， 资 源 清单 本 质 上 是 一 个 JSON 或 YAML 格 式 的 文本 
文件 ， 由 资源 对 象 的 配置 信息 组 成 ， 支 持 使 用 Git 等 进行 版 本 控制 。 而 
用 户 可 以 资源 清单 为 基础 ， 在 Kubernetes 系 统 上 以 陈述 式 或 声明 式 进 行 
资源 对 象 管理 ， 如 图 3-4 所 示 。 


| resources kind | ， Kubernetes Cluster 


El : 


/apis/<group>/<version>/ | 


= EI 
日 J Pid /binding | 


JSON 
/status 


Deployment 


API Server 


” 苹 etcd 3 


图 3-4 ”基于 资源 配置 清单 管理 对 象 


陈述 式 管理 方式 包 、` delete、get 和 replace 等 命令 ， 与 陈述 式 
命令 的 不 同 之 处 在 于 ， 它 通过 资 源 配置 消 单 谈 取 需要 管理 的 目标 资 沽 
对 象 。 陈 述 式 对 象 配置 的 管理 操作 直接 作用 于 活动 对 象 ， 即 便 仅 修改 
配置 注 妆 中 的 极 小 一 部 分 内 容 ， 使 用 replace 合 令 进 行 的 对 象 更 新 也 将 

导致 整个 对 象 被 奉 换 。 进 一 步 地 ， 混 合 使 用 陈述 式 命 令 进行 清单 文 
件 带 外 修改 时 ， 必然 会 导致 用 户 丢 失 活动 对 象 的 当前 状态 。 


声明 式 对 象 配置 并 不 直接 指明 要 进行 鸭 对 象 管理 操作 ， 而 是 提供 
配置 清单 文件 给 Kubernetes 系 统 ， 并 委托 系统 跟踪 活动 对 象 的 状态 变 
动 。 资 源 对 象 的 创建 、 删 除 及 修改 操作 全 部 通过 唯一 的 命令 apply 来 完 
成 ， 并 且 每 次 操作 时 ， 提 供给 命令 的 配置 信息 都 将 保存 于 对 象 的 注解 
信息 (kubectl.kubernetes.io/last-applied- a 中 ， 并 通过 对 比 
查 活动 对 象 的 当前 状态 、 注 解 中 的 配置 信息 及 资源 清单 中 的 配置 信 

三 方 进行 变更 合并 ， 从 而 实现 仪 修改 变 汉 动 字段 的 高 级 补 机制。 


陈述 式 对 象 配置 相 较 于 声明 式 对 象 配置 来 说， 其 缺点 在 于 同一 目 
了 永 下 的 配置 文件 必须 同时 进行 同一 种 操作 ， 例 如 ， 要 么 都 创建 ， 要 么 
都 更 新 等 ， 而 且 其 他 用 户 的 更 新 也 必须 反映 在 配置 文件 中 ， 不 然 其 更 
新 在 一 下 次 的 更 新 中 将 会 被 覆盖 。 因 此 ， 声 明 式 对 和 象 配 置 是 优先 推荐 
给 用 户 使 用 的 管理 机 制 。 


然而 ， 对 于 狐 手 来 说 ， 陈 述 式 命 令 的 配置 方式 最 易于 上 手 ， 对 系 
统 有 所 了 解 后 易于 切换 为 使 用 陈述 式 对 象 配置 管理 方式 。 因 此 ， 若 推 
荐 给 高 级 用 户 则 推荐 使 用 声明 式 配置 ， 并 建议 同时 使 用 版 本 控制 系统 
存储 所 期 望 的 状态 ， 以 及 跨 对 象 的 历史 信息 ， 并 启用 变更 复审 机 制 。 
另外 ， 推 荐 使 用 借助 于 kube-applier 等 一 类 的 项 目 实现 目 动 化 声明 式 配 
置 ， 用 户 将 配置 推送 到 Git 仓 库 中 ， 然 后 借助 此 类 工具 即 能 将 其 目 动 同 
步 于 Kubernetes 集 群 上 。 


3.3 ”kubectl 命 令 与 资源 管理 


API Server 是 Kubemetes 集 群 的 网 关 ， 用 户 和 管理 员 以 及 其 他 客户 
端 仅 能 通过 此 网 关 接 口 与 集群 进行 交互 。API 是 面 癌 程序 员 的 访问 接 
口 ， 目 前 可 较 好 地 文 持 Golang 和 Python 编程 语言 ， 当 然 ， 终 端 用 户 更 
为 常用 的 是 通用 命令 行 工 具 kubectl。 访 问 集群 之 前 ， 各 类 客户 端 需要 
了 解 集群 的 位 置 并 拥有 访问 集群 的 凭据 才能 获取 访问 许可 。 使 用 
kubeadm 进 行 集 群 初 始 化 时 ，kubeadm init 自 动 生成 
的 /etc/kubernetes/admin.conf 文 件 是 客户 端 接 入 当前 集群 时 使 用 的 
kubeconfig 文 件 ， 它 内 建 了 用 于 访问 Kubernetes 集 群 的 最 高 管理 权限 的 
用 户 账 号 及 相关 的 认证 凭据 ， 可 由 kubect 直接 使 用 。 


3.3.1 资源 管理 操作 概述 


资源 的 管理 操作 可 人 简单 归结 为 增 、 删 、 改 、 碍 四 种 ，kubectl 提 供 
了 一 系列 的 子 命令 用 于 执行 此 类 任务 ， 如 create、delete、patch、 
apply、replace、edit、get 等 ， 其 中 有 些 命令 必须 基于 资源 清单 来 进 
行 ， 如 apply 和 replace 命 令 ， 也 有 些 命 令 既 可 基于 清单 文件 进行 ， 也 可 
实时 作用 于 活动 资源 之 上 ， 如 create、get、patch 和 delete 等 。 


kubectl 命 令 能 够 读 取 任何 以 .yaml、.yml 或 .json 为 后 组 的 文件 〈 可 
称 为 配置 清单 或 配置 文件 ， 后 文 将 不 加 区 别 地 使 用 这 两 个 术语 ) 。 实 
践 中 ， 用 户 既 可 以 为 每 个 资源 使 用 专用 的 清单 文件 ， 也 可 以 将 多 个 相 
关 的 资源 (例如 ， 属 于 同一 个 应 用 或 微服 务 ， 组 织 在 同一 个 清单 文件 
中 。 不 过 ， 如 果 是 YAML 格 式 的 清单 文件 ， 多 个 资源 彼此 之 间 要 使 
用 “---” 符 号 作为 单独 的 一 行进 行 资源 分 割 。 这 样 ， 多 个 资源 就 将 以 清 
单 文件 中 定义 的 次 序 被 create、 apply 等 子 命令 调用 9 


kubect 的 多 数 子 命令 文 持 使 用 “- 邓 选项 指定 使 用 的 清单 文件 路 径 或 
URL， 也 可 以 古 存 储 有 清单 文件 的 目录 ， 男 外 ， 此 选项 在 同一 命令 中 
也 可 重复 使 用 多 次 。 如 采 指 定 的 目录 路 径 存 在 子 目 隶 中 时 ， 那 么 可 按 
需 同时 使 用 “-R” 选 项 以 递归 获取 子 目录 中 的 配置 清单 。 


再 者 ， 支 持 使 用 标签 和 注解 是 Kubernetes 系 统 的 一 大 特色 ， 它 为 
资源 管理 机 制 增色 不 少 ， 而 且 delete 和 get 等 命令 能 够 基于 标签 挑选 目 
标 对 象 ， 有 些 资源 甚至 必须 依赖 于 标签 才能 正常 使 用 和 工作 ， 例 如 
Service 和 Pod 探 制 狠 Deployment 等 资源 对 象 。 子 命令 label 用 于 管理 资源 
标签 ， 而 管理 资源 注解 的 子 命令 则 是 annotate 。 


就 地 更 新 (修改 ) 现 有 的 资源 也 是 一 种 常见 的 操作 。apply 命 令 通 
过 比较 资源 在 清单 文件 中 的 版 本 及 前 一 次 的 版 本 执行 更 新 操作 ， 它 不 
会 对 未 定义 的 属性 产生 额外 的 作用 。edit 命 令 相 当 于 先 使 用 get 命 令 获 
取 资 源 配置 ， 通 过 交互 式 编辑 器 修改 后 再 自动 使 用 apply 命 令 将 其 应 
用 。patch 命 令 基 于 JSON 补 本 、JSON 合 并 补丁 及 策略 合并 补丁 对 资源 
进行 瓯 地 更 新 操作 。 


@ 提示 “为 了 利用 apply 命 令 的 优势 ， 用 户 应 该 总 是 使 用 apply 


命令 或 create--save-config 命 令 创建 资源 。 


3.3.2 ”kubectl 的 基本 用 法 


kubectl 是 最 常用 的 客户 端 工具 之 一 ， 它 提供 了 基于 命令 行 访问 
Kubernetes API 的 简洁 方式 ， 能 够 满足 对 Kubernetes 的 绝 大 部 分 的 操作 
需求 。 例 如， 需要 创建 资源 对 象 时 ，kubectl 会 将 JSON 格 式 的 清单 内 容 
以 POST 方 式 提交 至 API Server°。 本 广 主 要 描述 kubectl 的 基本 功能 。 


@ 如 果 要 单独 部 署 kubectl，Kubernetes 也 提供 了 相应 的 
单独 发 行 包 ， 或 者 适 配 于 各 平台 的 程序 管理 器 的 相关 程序 包 ， 如 rpm 包 
或 deb 包 等 ， 用 户 根据 平台 类 型 的 不 同 获 取 相 匹配 的 版 本 安装 完成 即 
2 操作 步 又 类 似 于 前 面 的 安装 方法 ， 因 此 这 里 不 再 给 出 其 具体 过 


kubect 是 Kubernetes 系 统 的 命令 行 客 户 端 工具 ， 特 性 丰富 且 功 能 强 
大 ， 是 Kubernetes 管 理 员 最 利用 的 集群 管理 工具 。 其 最 基本 的 语法 格式 
为 “kubectl[command][TYPE][INAME][flags]”， 其 中 各 部 分 的 简要 说 明 如 
下 o 


1) command: 对 资源 执行 相应 操作 的 子 命令 ， 如 get 、create 、 
delete、run 等 ;常用 的 核心 子 命令 如 表 3-1 所 示 。 


2) TYPE: 要 操作 的 资源 对 象 的 类 型 ， 如 pods、services 等 ， 类 型 
名 称 区 分 字符 大 小 写 ， 但 支持 使 用 简写 格式 。 


3) NAME: 对 象 名 称 ， 区 分 字符 大 小 写 ;省略 时 ， 则 表示 指定 
TYPE 的 所 有 资源 对 象 ， 夯 外， 也 可 以 直接 使 用 “TYPE/NAME” 的 格式 
来 表示 资源 对 象 。 

4) flags: 命令 行 选项 ， 如 “-s” 或 “--server”， 男 外 ，get 等 命令 在 输 
出 时 还 有 一 个 常用 的 标志 “-o<format>” 用 于 指定 输出 格式 ， 如 表 3-1 所 
不 O 〇 


表 3-1 kubectl 的 子 命令 列表 


命令 命令 类 别 


create 
expose 
基础 命令 (初级 ) 
mn 
set 


get 


explain 


基础 命令 (中级) 


edit 
delete 
rollout 


rolling-update 

a 部 署 命 令 
autoscale 
certificate 
cluster-info 
top 

cordon 集群 管理 命令 
uncordon 

drain 

taint 

describe 

logs 

attach 

exec 和 
ee 排 错 及 调试 命令 
Pproxy 

cp 

auth 


功能 说 了 明 
通过 文件 或 标准 输入 创建 资源 
基于 rc 、service 、deployment 或 pod 创建 Service 资源 
通过 创建 Deployment 在 集群 中 运行 指定 的 镜像 
设置 指定 资源 的 特定 属性 
显示 一 个 或 多 个 资源 
打印 资源 文档 
编辑 资源 
基于 文件 名 、stdin、 资 源 或 名 字 ， 以 及 资源 和 选择 器 删除 资源 
管理 资源 的 滚动 更 新 
对 ReplicationController 执行 滚动 升级 
伸缩 Deployment、ReplicaSet、RC 或 Job 的 规模 
对 Deployment、ReplicaSet 或 RC 进行 自动 伸缩 
配置 数字 证 书 资源 
打印 集群 信息 
打印 资源 (CPU/Memory/Storage) 使 用 率 
将 指定 node 设 定 为 “不 可 用 ” (unschedulable) 状态 
将 指定 node 设 定 为 “可 用 "(schedulable) 状态 
“ 排 干 ”指定 的 node 的 负载 以 进入 “维护 ”模式 
为 node 声明 污点 及 标准 行为 
显示 指定 的 资源 或 资源 组 的 详细 信息 
显示 一 个 Pod 内 某 容器 的 日 志 
附加 终端 至 一 个 运行 中 的 容器 
在 容器 中 执行 指定 命令 
将 本 地 的 一 个 或 多 个 端口 转发 至 指定 的 Pod 
创建 能 够 访问 Kubernetes API Server 的 代理 
在 容器 间 复 制 文 件 或 目录 
打印 授权 信息 


命令 命令 类 别 
apply 
patch 


高 级 命令 


replace 
convert 
label 
annotate 
completion 
version 
api-versions 
config 其 他 命令 
plugin 


help 


kubectl 命 令 还 包含 了 多 种 不 同 的 输出 格式 《如 表 3-2 所 示 ) ， 它 们 
为 用 户 提 供 了 非 稼 灵活 的 目 定义 输出 机 制 ， 如 输出 为 YAML 或 JSON 格 


功能 说 明 
基于 文件 或 stdin 将 配置 应 用 于 资源 
使 用 策略 合并 补丁 更 新 资源 字段 
基于 文件 或 stdin 替换 一 个 资源 
为 不 同 的 API 版 本 转换 配置 文件 
更 新 指定 资源 的 label 
更 新 资源 的 annotationl| 
输出 指定 的 shell (如 bash) 的 补 全 码 
打印 Kubernetes 服务 端 和 客户 端的 版 本 信息 
以 “group/version ”格式 打印 服务 器 支持 的 API 版 本 信息 
配置 kubeconfig 文件 的 内 容 
运行 命令 行 插 件 
打印 任 一 命令 的 帮助 信息 


表 3-2 ”kubectl get 命 令 的 常用 输出 格式 


输出 格式 
-0 Wide 
-0 name 
-0 yaml 
-0 json 
-0 go-template 


-0 custom-columns 


此 外 ，kubect 命 令 还 有 许多 通用 的 选项 ， 


格式 说 明 
显示 资源 的 额外 信息 
仅 打印 资源 的 名 称 
YAML 格式 化 输出 API 对 象 信息 
JSON 格式 化 输出 API 对 象 信息 
以 自 定义 的 go 模板 格式 化 输出 API 对 象 信息 
自 定义 要 输出 的 字段 


options” 命 令 来 获取 。 下 面 列举 儿 个 比较 利用 命令 。 


:-s 或 --server: 指定 API Server 的 地 址 和 端口 。 


.--kubeconfig: 使 用 的 kubeconfig 文 件 路 径 ， 默 认为 ~/.kube/config 。 


--namespace: 命令 执行 的 目标 名 称 空间 。 


kubect 的 部 分 子 命令 在 第 2 章 已 经 多 次 提 到 ， 余 下 的 大 多 数 命 令 在 
后 续 的 章 市 中 还 会 用 到 ， 对 于 它们 的 使 用 说 明 也 将 在 首次 用 到 时 进行 


这 个 可 以 使 用 “kubectl 


展开 说 明 。 


3.4 审理 名 称 空间 质 源 


名 称 空 间 (Namespace) 是 Kubernetes 集 群 级 别 的 资源 ， 用 于 将 集 
群 分 隔 为 多 个 隔离 的 逻辑 分 区 以 配置 给 不 同 的 用 户 、 和 租户、 环境 或 项 
目 使 用 ， 例 如 ， 可 以 为 development、qa 和 production 应 用 环境 分 别 创建 
各 目的 名 称 空间 。 


Kubernetes 的 绝 大 多 数 资源 都 隶属 于 名 称 空 间 级 别 ( 男 一 个 是 全 
局 级 别 或 集群 级 别 ) ， 和 名称 空间 资源 为 这 类 的 资源 名 称 提 供 了 隔离 的 
作用 域 ， 同 一 名 称 空间 内 的 同一 类 型 资源 名 必须 是 唯一 的 ， 但 跨 名 称 
空间 时 并 无 此 限制 。 不 过 ，Kubernetes 还 是 有 一 些 资源 隶属 于 集群 级 
别 的 ， 如 Node、Namespace 和 PersistentVolume 等 资源 ， 它 们 不 属于 任 
何 名 称 空 间 ， 因 此 资源 对 象 的 名 称 必须 全 局 唯一 。 


O 注意 ”Kubernetes 的 名 称 空间 资源 不 同 于 Linux 系 统 的 名 称 空 
间 ， 它 们 是 各 自 独立 的 概念 。 另 外 ，Kubernetes 名 称 空间 并 不 能 实现 
Pod 间 的 通信 隔离 ， 它 仅 用 于 限制 货源 对 象 名 称 的 作用 域 。 


3.4.1 查看 名 称 空 间 及 其 资源 对 象 


Kubernetes 集 群 默认 提供 了 几 个 名 称 空 间 用 于 特定 的 目的 ， 例 
如 ，kube-system 主 要 用 于 运行 系统 级 资源 ， 而 default 则 为 那些 未 指定 
名 称 空 间 的 资源 操作 提供 一 个 默认 值 ， 前 面 章 和 中 的 绝 大 多 数 资源 管 
理 操 作 都 在 default 名 称 空间 中 进行 。“kubectl get namespaces” 命 令 则 可 
以 查看 namespaces 资 源 : 


~]$ kubect1 get namespaces 
NAME STATUS AGE 
default Active 6d 
kube-public Active 6d 
kube-system Active 6d 


也 可 以 使 用 “kubectl describe namespaces” 命 令 查 看 特定 名 称 空间 的 
详细 信息 ， 例 如 : 


~]$ kubectl1 describe namespaces default 


kubectl 的 资源 查看 命令 在 多 数 情 况 下 应 该 针对 特定 的 名 称 空间 来 
进行 ， 为 其 使 用 “-n” 或 “--namespace” 选 项 即 可 ， 例 如 ， 查 看 kube- 
system 下 的 所 有 Pod 资 源 : 


~]$ kubectl1 get pods -n kube-system 


NAME READY STATUS RESTARTS AGE 
etcd-master.ikubernetes.io 1/1 Running 1 6d 
kube-apiserver-master.ikubernetes.io 1/1 Running 1 6d 


命令 结果 显示 出 kube-system 与 default 名 称 空 间 的 Pod 资 源 对 象 并 不 
相同 ， 这 正 是 Namespace 资 源 的 名 称 隅 离 功能 的 体现 。 有 了 Namespace 
对 象 ， 用 户 再 也 不 必 精 心安 排 资 源 名 称 ， 也 不 用 担心 误 操 作 了 其 他 用 
户 的 资源 。 


3.4.2 ”管理 Namespace 资 源 


Namespace 是 Kubernetes API 的 标准 资源 类 型 之 一 ， 如 3.2.1 广 中 所 
述 ， 它 的 配置 主要 有 kind、apiVersion、metadata 和 spec 等 一 级 字段 组 
成 。 将 3.2.1 世 中 的 名 称 空 间 配置 清单 保存 于 配置 文件 中 ， 使 用 陈述 式 
对 象 配置 命令 create 或 声明 式 对 象 配置 命令 apply 便 能 完成 创建 : 


~]$ kubectl apply -f namespace-example.yaml 
namespace/dev created 


名 称 空间 资源 属性 较 少 (通常 只 需要 指定 名 称 即 可 ) ， 简 单 起 
见 ，kubectl 为 其 提供 了 一 个 封 效 的 专用 陈述 式 命令 “kubectl] create 
namespace”。Namespace 资 源 的 名 称 仅 能 由 字母 、 数 字 、 连 接线 、 下 划 
0 。 例如 ， 下 面 的 命令 可 用 于 创建 名 为 qa 的 Namespace 对 


~]$ kubect1l create namespace qa 
namespace/qa created 


和 
S 注意 A 、 数字 、 连 接线 、 
下 划 线 等 字符 组 成 。 


实践 中 ， 不 建议 混用 不 同类 别 的 管理 方式 。 考 虑 到 声明 式 对 象 配 
置 管理 机 制 的 强大 功能 ， 强 烈 推荐 用 户 使 用 apply 和 patch 等 命令 进行 资 
源 创建 及 修改 一 类 的 管理 操作 。 

使 用 kubectl 管 理 资 源 时 ， 如 果 一 并 提供 了 名 称 空 间 选 项 ， 残 表示 
此 管理 操作 仅 针 对 指定 名 称 空间 进行 ， 而 删除 Namespace 资 源 会 级 联 删 
除 其 包含 的 所 有 其 他 资源 对 象 。 表 3-3 给 出 了 几 个 党 用 的 命令 格式 。 


表 3-3 结合 名 称 空间 使 用 的 删除 命令 


命令 格式 功能 


kubectl delete TYPE RESOURCE -n NS 删除 指定 名 称 空间 内 的 指定 资源 
kubectl delete TYPE --all -n NS 删除 指定 名 称 空间 内 的 指定 类 型 的 所 有 资源 
kubectl delete all -n NS 删除 指定 名 称 空 间 内 的 所 有 资源 
kubectl delete all --all 删除 所 有 名 称 空间 中 的 所 有 资源 


需要 再 次 指出 的 是 ，Namespace 对 象 仅 用 于 资源 对 象 名 称 的 隔离 ， 
它 自身 并 不 能 隔绝 跨 名 称 空间 的 Pod 间 通信 ， 那 是 网 络 策略 (network 
policy) 资源 的 功能 。 


3.5 “Pod 和 货源 的 基础 管理 操作 


Pod 是 Kubernetes API 中 的 核心 资源 类 型 ， 它 可 以 定义 在 JSON 或 
YAML 格 式 的 资源 清单 中 ， 由 资源 管理 命令 进行 陈述 式 或 声明 式 管 
理 。 创 建 时 ， 用 户 通过 create 或 apply 命 令 将 请 求 提 交 到 API Server 并 将 
其 保存 至 集群 状态 存储 系统 etcd 中 ， 而 后 由 调度 厚 将 其 调度 至 最 住 目 
标 节 点 ， 并 被 相应 闻 点 的 kubelet 借 助 于 容器 引擎 创建 并 启动 。 这 种 由 
用 户 直接 通过 API 创 建 的 Pod 对 象 也 称 为 自主 式 Pod。 


3.5.1 陈述 式 对 象 配 置 管理 方式 


陈述 式 对 象 配置 管理 机 制 ， 是 由 用 户 通过 配置 文件 指定 要 管理 的 
目标 资源 对 象 ， 而 后 再 由 用 户 借助 于 命令 直接 指定 Kubemetes 系 统 要 
执行 的 管理 操作 的 管理 方式 ， 常 用 的 命令 有 create 、delete 、replace 、 
get 和 describe 等 。 


1. 创 建 Pod 资 源 


Pod 是 标准 的 Kubernetes API 资 源 ， 在 配置 清单 中 使 用 kind、 
apiVersion、metadata 和 spec 字 上 段 进行 定义 ，status 字 段 在 对 象 创建 后 由 
系统 上 自行 维护 。Pod 对 象 的 核心 功用 在 于 运行 容器 化 应 用 ， 在 其 spec 字 
段 中 航 套 的 必 选 字段 是 containers， 它 的 值 是 一 个 容器 对 象 列表 ， 支 持 
藤 套 创建 一 到 多 个 容器 。 下 面 是 一 个 Pod 资 源 清 单 示 例文 件 ， 在 spec 中 
定义 的 期 户 的 状态 是 在 Pod 对 象 中 基于 ikubermmetes/myapp: V1 镜像 运行 
一 个 名 为 myapp 的 容器 : 


apiVersion: v1 
kind: Pod 
metadata: 

name: pod-example 
spec: 

containers: 

- name: myapp 

image: ikubernetes/myapp:v1 


把 上 面 的 内 容 保 存 于 配置 文件 中 ， 使 用 “kubectl[lCOMMAND]- 
f/PATH/TO/YAML_FILF” 命 令 以 陈述 式 对 和 象 配 置 进 行 资源 对 和 象 的 创 
建 ， 下 面 是 相应 的 命令 及 啊 应 结 


~]$ kubectl create -f pod-example.yaml 
pod/pod-example created 


@ ，: 如 果 读 者 熟悉 JSON， 也 可 以 直接 将 清单 文件 定义 为 
JSON 格 式 ; YAML 格 式 的 清单 文件 本 身 也 是 由 API Server 事 先 将 其 转 
换 为 JSON 格 式 而 后 才 进 行 应 用 的 。 


命令 的 返回 信息 表示 目标 Pod 对 象 pod-example 得 以 成 功 创建 。 事 
实 上 ，create 命 令 中 的 -{ 选 项 也 文 持 使 用 目录 路 径 或 URL， 而 且 目 标 路 
径 为 目 永 时 ， 还 文 持 使 用 -R 选 项 进行 子 目 孙 递归 。 另 外 ，--record 选 项 
可 以 将 命令 本 里 记 杂 为 目标 对 象 的 注解 信息 kubernetes.io/change- 
cause ， 而 --save-config 则 能 够 将 提供 给 命令 的 资源 对 象 配 置信 息 你 存 
于 对 象 的 注解 信息 kubectl.kubernetes.io/last-applied-configuration 中 ， 后 
一 个 命令 的 功用 与 声明 式 对 象 配 置 命 令 apply 的 功能 相近 。 


2. 查 看 Pod 状 态 


get 命 令 默 认 显示 资源 对 象 最 为 关键 的 状态 信息 ， 而 describe 等 命 
令 则 能 够 打印 出 Kubernetes 资 源 对 象 的 详细 状态 。 不 过 ， 虽 然 创 建 时 
给 出 的 资源 清单 文件 较为 答 洁 ， 但 “kubectl get” 命 令 既 可 以 使 用 “-o 
yaml 或 “-o json2 选 项 输出 资源 对 象 的 配置 数据 及 状态 ， 也 能 够 借助 
于 “--custom-columns” 选 项 目 定义 要 显示 的 字段 : 


~]$ kubect1 get -f pod-example.yaml 

NAME READY STATUS RESTARTS AGE 
pod-example 1/1 Running 0 1m 
~]$ kubectl1 get -f pod-example.yaml -0 custom- 
columns=NAME :metadata.name, STATUS: status.phase 
NAME STATUS 

pod-example Running 


使 用 “-o yaml” 或 “-o json” 选 项 时 ，get 命 令 能 够 返回 资源 对 象 的 元 
数据 、 期 望 的 状态 及 当前 状态 数据 信息 ， 而 要 打印 活动 对 象 的 详细 信 
轧 ， 则 需要 describe 命 令 ， 它 可 根据 资源 请 单 、 资 源 名 或 卷 标 等 方式 过 
滤 输 出 符合 条 件 的 资源 对 象 的 信息 。 命 令 格式 为 "kubectl describe (-f 
FILENAME|TYPE[NAME_PREFIX|-] label]|lTYPE/NAME) ”。 例如， 
显示 pod-example 的 详细 信息 ， 可 使 用 类 似 如 下 的 命令 : 


~]$ kubectl1 describe -f pod-example.yaml 


对 于 Pod 资 源 对 象 来 说 ， 它 能 够 返回 活动 对 象 的 元 数据 、 当 前 状 
仿 、 容 器 列表 及 各 容 右 的 评 情 、 存 储 卷 对象 列 表 、QoS 类 别 、 事 件 及 
相关 信息 ， 这 些 详 情 对 于 了 解 目 标 资源 对 象 的 状态 或 进行 错误 排 碍 等 
操作 来 说 至 天 重要 。 


3. 更 新 Pod 资 源 


对 于 活动 对 象 ， 并 非 其 每 个 属性 值 都 支持 修改 ， 例 如 ，Pod 资 源 
对 象 的 metadata.name 字 段 承 不 文 持 修改 ， 除 非 删除 并 重建 它 。 对 于 那 
些 文 持 修改 的 属性 ， 比 如 ， 容 器 的 image 字 段 ， 可 将 其 完整 的 配置 清单 
导出 于 配置 文件 中 并 更 新 相应 的 配置 数据 ， 而 后 使 用 replace 命 令 基于 
陈述 式 对 象 配 置 的 管理 机 制 进行 资源 对 象 的 更 新 。 例 如 ， 将 前 面 创建 
pod-example 时 使 用 的 资源 清单 中 的 image 值 修改 
为 “ikubernetes/myapp: v2”， 而 后 执行 更 新 操作 : 


~]$ kubect1 get pods pod-example -0o yaml > pod-example-update.yaml 

~]$ sed -i 's@\(image:\).*@ikubernetes/myapp:v2@' pod-example-update.yaml 
~]$ kubectl1 replace -f pod-example-update.yaml 

pod/pod-example replaced 


更 新 活动 对 象 的 配置 时 ， 令 要 重 构 整 个 资源 对 象 ， 故 此 
它 必 须 基 于 完整 格式 的 配置 信息 才能 进行 活动 对 象 的 完全 替换 。 帮 要 
基于 此 前 的 配置 文件 进行 蔡 换 ， 残 必须 使 用 --force 选 项 删除 此 前 的 活 
动 对 象 ， 而 后 再 进行 狐 建 操作 ， 否 则 命令 会 返回 错误 信息 。 例 如 ， 将 
前 面 第 一 步 “ 创 建 Pod 资 源 ” 内 的 配置 清单 中 的 镜像 修改 
为 “ikubernetes/myapp: V2” 后 再 进行 强制 奉 换 ， 命 令 如 下 : 


~]$ kubectl1 replace -f pod-example.yaml --force 
pod "pod-example" deleted 
pod/pod-example replaced 


4. 删 除 Pod 资 源 


陈述 式 对 象 配置 管理 方式 下 的 删除 操作 与 创建 、 查 看 及 更 新 操作 
类 似 ， 为 delete 命 令 使 用 -f 选 项 指定 配置 清单 即 可 ， 例 如 ， 删 除 pod- 
example.yaml 文 件 中 定义 的 Pod 资 源 对 象 : 


~]$ kubect1 delete -f pod-example.yaml 
pod "pod-example" deleted 


， 是 中 对象 即 可 验 正 其 删除 的 
结 采 ， 例 如 


~]$ kubectl1 get -f pod-example.yaml 
No resources found. 
Error from server (NotFound): pods "pod-example" not found 


3.5.2” 志 明 式 对 象 配 置 管理 方式 


陈述 式 对 象 配 置 管理 机 制 中 ， 同 时 指定 的 多 个 资源 必须 进行 同一 
种 操作 ， 而 且 其 replace 命 仿古 通过 完全 若 换 现 有 的 活动 对 象 来 进行 资 
源 的 更 新 操作 ， 对 于 生产 环境 来 说 ， 这 并 非 理 想 的 选择 。 声 明 式 对 象 
配置 操作 在 管理 资源 对 象 时 将 配置 信息 保存 于 目标 对 象 的 注解 中 ， 并 
通过 比较 活动 对 象 的 当前 配置 、 前 一 次 管理 操作 时 保存 于 注解 中 的 配 
置 ， 以 及 当前 命令 提供 的 配置 生成 更 新 补丁 从 而 完成 活动 对 象 的 补丁 
式 更 新 操作 。 此 类 管理 操作 的 常用 命令 有 apply 和 patch 等 。 


例如 ， 创 建 3.5.1 节 中 定义 的 主 容 髓 使 用 *"ikubernetes/myapp: V1” 镜 
像 的 Pod 资 源 对 象 ， 还 可 以 使 用 如 下 命令 进行 : 


~]$ kubectl1 apply -f pod-example.yaml 
pod/pod-example created 


而 更 新 对 象 的 操作 ， 可 在 直接 修改 原 有 资源 清单 文件 后 再 次 对 其 
执行 apply 命 令 来 完成 ， 例 如 ， 修 改 Pod 资 源 配置 清单 中 的 镜像 文件 
为 “ikubernetes/myapp: v2” 后 再 次 执行 如 上 的 apply 命 令 : 


~]$ kubectl1 apply -f pod-example.yaml 
pod/pod-example configured 


命令 结果 显示 资源 重新 配置 完成 并 且 已 经 生效 。 事 实 上 ， 此 类 操 
作 也 完全 能 够 使 用 patch 命 令 直 接 进 行 补 丁 操 作 。 而 资源 对 象 的 删除 操 
作 依 然 可 以 使 用 apply 命 令 ， 但 要 同时 使 用 --prune 选 项 ， 命 令 的 格式 
为 “kubectl apply-f<directory/>--prune-l<labels>”。 需 要 注意 的 是 ， 此 命 
令 异 常 凶 险 ， 因 为 它 将 基于 标签 选择 右 过 滤 出 所 有 符合 条 件 的 对 象 ， 
并 检查 由 -f 指 定 的 目录 中 是 否 存在 某 配置 文件 已 经 定义 了 相应 的 资源 
对 象 ， 那 些 不 存在 相应 定义 的 资源 对 象 将 被 删除 。 因 此 ， 删 除 资 源 对 
象 的 操作 依然 建议 使 用 陈述 式 对 象 配置 方式 的 命令 *kubectl delete” 进 
行 ， 这 样 的 命令 格式 操作 目标 明确 有 旦 不 易 出 现 偏差 。 


3.6 本章 小 结 


本 章 介 绍 了 Kubernetes 系 统 上 常用 的 资源 对 象 类 型 及 其 管理 方 
式 ， 在 说 明 kubectl 命 令 行 工 具 的 基础 用 法 后 借助 于 Namespace 资 源 对 
象 简单 说 明了 其 使 用 方式 ， 具 体 如 下 。 


-Kubernetes 提 供 了 RESTful 风 格 的 API， 它 将 各 类 组 件 均 抽象 为 “ 资 
源 ”， 并 通过 属性 赋值 完成 实例 化 。 

Kubernetes API 支 持 的 资源 类 型 众多 ， 包 括 Node、Namespace 、 
Pod、Service、Deployment、ConfigMap 等 上 百 种 。 


.标准 格式 的 资源 配置 大 多 都 是 由 kind、apiVersion、metadata、 
spec 和 status 等 一 级 属性 字段 组 成 ， 其 中 spec 是 由 用 户 定 义 的 期 望 状 
态 ， 而 status 则 是 由 系统 维护 的 当前 状态 。 


Kubernetes API 主 要 提供 的 是 声明 式 对 象 配置 接口 ， 但 它 也 文 持 
陈述 式 命令 及 陈述 式 对 象 配置 的 管理 方式 。 


-kubectl 命 令 功能 从 多 ， 它 将 通过 子 命令 完成 不 同 的 任务 ， 如 
create 、 delete、edit、replace、apply 等 。 


.Namespace 和 Pod 是 Kubernetes 系 统 的 基础 资源 类 型 。 


第 4 章 ”管理 Pod 资 源 对 象 


Pod 是 Kubernetes 系 统 的 基础 单元 ， 是 资源 对 象 模型 中 可 由 用 户 创 
建 或 部 署 的 最 小 组 件 ， 也 是 在 Kubernetes 系 统 上 运行 容 絮 化 应 用 的 资 
源 对 象 。 其 他 的 大 多 数 资源 对 象 都 是 用 于 支撑 和 扩展 Pod 对 象 功 能 
的 ， 例 如 ， 用 于 管控 Pod 运 行 的 StatefulSet 和 Deployment 等 控制 器 对 
象 ， 用 于 桑 露 Pod 必 用 的 Service 和 Ingress 对 象 ， 为 Pod 提 供 存 储 的 
PersistentVolume 存 储 资源 对 象 等 。 这 些 资源 对 象 大 体 可 分 为 有 限 的 几 
个 类 别 ， 并 且 可 基于 资源 清单 作为 资源 配置 文件 进行 陈述 式 或 声明 式 
管理 。 本 章 将 描述 这 些 类 别 ， 并 详细 介绍 Pod 资 源 的 基础 应 用 。 


4.1 容器 与 Pod 资 源 对 象 


现代 的 容器 技术 被 设计 用 来 运行 单个 进程 《包括 子 进程 ) 时 ， 该 
进程 在 容 姻 中 PID 名 称 空间 中 的 进程 号 为 1， 可 直接 接收 并 处 理 信号， 
于 是 ， 在 此 进程 终止 时 ， 容 姨 即 终止 退出 。 若 要 在 一 个 容 絮 内 运行 多 
个 进程 ， 则 需要 为 这 些 进 程 提 供 一 个 类 似 于 Linux 操 作 系 统 init 进 程 的 管 
控 类 进程 ， 以 树 状 结构 完成 多 进程 的 生命 周期 管理 ， 例 如 ， 裔 并 后 回 
收 相应 的 系统 资源 等 。 单 容器 运行 多 进程 时 ， 通 常 还 需要 日 志 进 程 来 
管理 这 些 进 程 的 日 志 ， 例 如 ， 将 它们 分 别 保存 于 不 同 的 目标 日 志文 件 
等 ， 否 则 用 户 束 不 得 不 手动 来 分 拒 日 志 信 息 。 因 此 ， 绝 大 多 数 场景 中 
都 应 该 于 一 个 容 怖 中 仅 运 行 一 个 进程 ， 它 将 日 志 信 息 直 接 输出 至 容 需 
的 标准 输出 ， 支 持 用 户 直接 使 用 命令 (kubectl logs) 进行 获取 ， 这 也 是 
Docker 及 Kubemetes 使 用 容 姻 的 标准 方式 。 


不 过 ， 分别 运行 于 各 上 自 容 器 的 进程 之 间 无 法 实现 基于 IPC 的 通信 机 
制 ， 此 时 ， 容 右 间 的 隅 离 机 制 对 于 依赖 于 此 类 通信 方式 的 进程 来 说 却 
又 成 了 阻碍 。Pod 资 源 抽 和 象 正 是 用 来 解决 此 类 问题 的 组 件 ， 前 文 已 然 多 
次 提 到 ，Pod 对 象 是 一 组 容器 的 集合 ， 这 些 容器 共享 Network、UTS 及 
IPC 名 称 空 间 ， 因 此 具有 相同 的 域名 、 主 机 名 和 网 络 接口 ， 并 可 通过 
IPC 直 接 通 信 。 为 一 个 Pod 对 象 中 的 各 容器 提供 网 络 名 称 空间 等 共享 机 
制 的 是 底层 基础 容器 pause， 图 4-1 所 示 为 一 个 由 三 个 容器 组 成 的 Pod 资 
源 ， 各 容器 共享 Network、IPC 和 和 UTS 名称 空 间 ， 但 分 别 拥有 各 自 的 
MNT、USR 和 和 PID 名称 空 间 。 需 要 特别 强调 的 是 ， 一 个 Pod 对 象 中 的 多 
个 容 种 必须 运行 于 同一 工作 和 所 之 上 。 


Pod 
pause 


PID、 Mount、 User 


IPC、 UTS、 Network | 


Containerl Container2 
PID、 Mount、 User|| PID、Mount、User 


图 4-1 “Pod 内 的 容器 共享 Network、IPC 和 UTS 名 称 空间 


尽管 可 以 将 Pod 类 比 为 物理 机 或 VM， 但 一 个 Pod 内 通常 仅 应 该 运行 
一 个 应 用 ， 除 非 多 个 进程 之 间 具 有 密切 的 关系 。 这 也 意味 着 ， 实 践 中 
应 该 将 多 个 应 用 分 别 构 建 到 多 个 而 非 单 个 Pod 中 ， 这 样 也 更 能 符合 容 絮 
的 轻 量 化 设计 、 运 行 之 目的 。 


例如 ， 一 个 有 着 前 端 (application server) 和 后 端 (database 

server) 的 应 用 ， 其 前 、 后 端 应 该 分 别 组 织 于 各 自 的 Pod 中 ， 而 非 同一 
Pod 的 不 同 容器 中 。 这 样 做 的 好 处 在 于 ， 多 个 Pod 可 被 调度 至 多 个 不 同 
的 主机 运行 ， 提 高 了 资源 利用 率 。 另 外 ，Pod 也 是 Kubernetes 进 行 系统 
规模 伸缩 的 基础 单元 ， 分 别 运行 于 不 同 Pod 的 多 个 应 用 可 独立 按 需 进行 
规模 变动 ， 这 束 增 强 了 系统 架构 的 灵活 性 。 事 实 上 ， 前 、 后 端 应 用 的 
规模 需求 通常 不 会 相同 ， 而 且 无 状态 应 用 (application server) 的 规模 
变动 也 比 有 状态 应 用 (database server) 容易 得 多 ， 将 它们 组 织 于 同一 
Pod 中 时 将 无 法 享受 这 种 便利 。 


不 过 ， 有 些 场景 要 求 必须 于 同一 Pod 中 同时 运行 多 个 容器 。 此 时 ， 
这 些 分 布 式 应 用 (尤其 是 微服 务 染 构 中 的 多 个 服务 ) 必须 遵循 某 些 最 
佳 实践 机 制 或 基本 准则 。 事 实 上 ，Kubernetes 并 非 期 望 成 为 一 个 管理 系 
统 ， 而 十 一 个 支持 这 些 最 佳 实践 的 向 开发 人 员 或 管理 人 员 提 供 更 高 级 
别 服务 的 系统 。 分 布 式 系统 设计 通常 包含 以 下 几 种 模型 。 


1) Sidecar pattern 〈 边 车 模型 或 跨 斗 模型 ) : 即 为 Pod 的 主 应 用 容 
器 提供 协同 的 辅助 应 用 容器 ， 每 个 应 用 独立 运行 ， 最 为 典型 的 代表 是 
将 主 应 用 容 右 中 的 日 志 使 用 agent 收 集 至 日 志 服 务 右 中 时 ， 可 以 将 agent 
运行 为 辅助 应 用 容 右 ， 即 sidecar。 男 一 个 典型 的 应 用 是 为 主 应 用 容 絮 中 
的 database server 局 用 本 地 缓存 ， 如 图 4-2 所 示 。 


PE 


A Node UDS CB Redis 
Backend ee Ws Cache 
MAIN CONTAINER SIDECAR 


图 4-2 Sidecar pattern 


2) Ambassador pattern 〈 大 使 模型 ) : 即 为 远程 服务 创建 一 个 本 地 
代理 ， 代 理应 用 运行 于 容器 中 ， 主 容 絮 中 的 应 用 通过 代理 容器 访问 远 
程 服务 ， 如 图 4-3 所 示 。 一 个 典型 的 使 用 示例 是 主 应 用 容器 中 的 进程 访 
问 “ 一 主 多 从 ”模型 的 远程 Redis 应 用 上 时， 可 在 当前 Pod 容 絮 中 为 Redis 服 
务 创建 一 个 Ambassador container， 主 应 用 容器 中 的 进程 直接 通过 
localhost 接 口 访问 Ambassador container 即 9 可。 即便 是 Redis 主 从 集群 架构 
发 生变 动 时 ， 也 仅 需 要 将 Ambassador container 加 以 修改 即 可 ， 主 应 用 
容器 无 须 对 此 做 出 任何 反应 。 
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图 4-3 Ambassador pattern 


3) Adapter pattern (适配器 模型 ，: 此 种 模型 一 般 用 于 将 主 应 用 容 
狼 中 的 内 容 进 行 标 准 化 输出 ， 例 如 ， 日 志 数 据 或 指标 数据 的 输出 ， 这 


有 助 于 调用 者 统一 接收 数据 的 接口 ， 如 图 4.4 所 示 。 另 外 ， 某 应 用 滚动 

升级 后 的 版 本 不 兼容 旧 的 版 本 时 ， 其 报告 信息 的 格式 也 存在 不 兼容 的 

可 能 性 ， 使 用 Adapter container 有 助 了 小 免 于 此 调用 此 报告 数据 的 应 有 
关 误 。 


PE 
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图 4-4 Adapter pattern 


Kubernetes 系 统 的 Pod 资 源 对 象 用 于 运行 单个 容器 化 应 用 ， 此 应 用 
称 为 Pod 对 象 的 主 容器 (main container) ， 同 时 Pod 也 能 容纳 多 个 容 
个 过 颁 外 的 容 右 一 艇 工作 为 Sidecar 模 于 ， 用 于 辅助 主 容 咽 完成 工 
只 能 。 


4.2 ”管理 Pod 对 象 的 容器 


一 个 Pod 对 象 中 至 少 要 存在 一 个 容 右 ， 因 此 ，containers 字 段 是 定 
义 Pod 时 其 欲 套 字段 Spec 中 的 必 选 项 ， 用 于 为 Pod 指 定 要 创建 的 容器 列 
表 。 进 行 容 器 配置 时 ，name 为 必 选 字段 ， 用 于 指定 容 娘 名 称 ，image 
字段 是 为 可 选 ， 以 方便 更 高 级 别 的 管理 类 资源 (如 Deployment) 等 能 
禾 盖 此 字段 ， 于 是 自主 式 的 Pod 并 不 可 省 略 此 字段 。 因此， 定义 一 个 
容器 的 基础 框 钦 如 下 : 


name: CONTAINER_NAME 
Image: IMAGE_FILE_NAME 


此 外 ， 定 义 容 器 时 还 有 一 些 其 他 常用 的 字段 ， 例 如 ， 定 义 要 暴露 
` 传递 环境 变量 、 定 义 可 用 的 系统 
资源 配额 等 。 


4.2.1 ”镜像 及 其 获取 策略 


各 工作 节点 负责 运行 Pod 对 象 ， 而 Pod 的 核心 功用 在 于 运行 容器 ， 
因此 工作 市 点 上 必须 配置 容器 运行 引擎 ， 如 Docker 等 。 启 动容 器 时 ， 
容器 引擎 将 首先 于 本 地 查找 指定 的 镜像 文件 ， 不 存在 的 镜像 则 需要 从 
指定 的 镜像 仓库 (Registry) 下 载 至 本 地 ， 如 图 4-5 所 示 。 


DOCKER_ HOST 


Docker daemon 


Imasges ~ 


图 4-5 Docker 及 其 Registry 


Kubernetes 系 统 文 持 用 户 自 定义 镜像 文件 的 获取 策略 ， 例 如 在 网 络 
资源 较为 紧张 时 可 以 禁止 从 仓库 中 获取 镜像 文件 等 。 容 句 
的 “imagePullPolicy” 字 段 用 于 为 其 指定 镜像 获取 策略 ， 它 的 可 用 值 包括 
下 Js 

.Always: 镜像 标签 为 "latest” 或 镜像 不 存在 时 总 是 从 指定 的 仓库 中 
获取 镜像 。 


.IfNotPresent: 仅 当 本 地 镜像 缺失 时 方才 从 目标 仓库 下 载 镜像 。 
.Never: 禁止 从 仓库 下 载 镜像 ， 即 仪 使 用 本 地 镜像 。 
下 面 的 资源 清单 中 的 容器 定义 了 如 何 使 用 nginx: latest 镜 像 ， 其 获 


取 筑 略为 Always， 这 意味 着 每 次 启动 容 絮 时， 它 都 会 到 镜像 仓库 中 获 
取 最 新 版 本 的 镜像 文件 : 


apiVersion: v1 
kind: Pod 
metadata: 

name: nginx-pod 
spec: 

containers: 

- name: nginx 

image: nginx:latest 
imagePullPolicy: Always 


对 于 标签 为 “atest” 的 镜像 文件 ， 其 默认 的 镜像 获取 策略 即 
为 "Always”， 而 对 于 其 他 标 等 的 镜像 ， 其 默认 策略 则 
为 “IfNotPresent”。 需 要 注意 的 是 ， 使 用 私有 仓库 中 的 镜像 时 通常 需要 
由 Registry 服 务 器 完成 认证 后 才能 进行 。 认 证 过 程 要 么 需要 在 相关 市 点 
上 交互 式 执行 docker login 命 令 来 进行 ， 要么 就 是 将 认证 信息 定义 为 专 
有 的 Secret 资 源 ， 并 配置 Pod 通 过 “imagePullSecretes” 字 7 段 调用 此 认证 信 
息 完成 。 后 面 8.5 节 会 详细 介绍 此 功能 及 其 实现 。 


4.2.2 ”又 露 端口 


Docker 的 网 络 模型 中 ， 使 用 默认 网 络 的 容 希 化 应 用 需 通过 NAT 机 
制 将 其 “其 露 ” (expose) 到 外 部 网 络 中 才能 被 其 他 市 点 之 上 的 容 右 客 
尸 端 所 访问 。 然 而 ，Kubermetes 系 统 的 网 络 模 型 中 ， 各 Pod 的 IP 地 址 处 
于 同一 网 络 平 面 ， 无 论 是 否 为 容 需 指定 了 要 骏 露 的 端口 ， 都 不 会 影响 
集群 中 其 他 节点 之 上 的 Pod 客 户 端 对 其 进行 访问 ， 这 就 意味 着 ， 任 何 
监听 在 非 1o 接 口上 的 问 口 都 可 以 通过 Pod 网 络 直 接 极 请 求 。 从 这 个 角度 
来 说 ， 容 需 问 口上 只 是 信息 性 数据 ， 它 只 是 为 集群 用 户 提供 一 个 快速 了 
解 相 关 Pod 对 象 的 可 访问 站 口 的 途径 ， 而 且 显 式 指 定 容 融 端口 ， 还 能 
为 其 赋予 一 个 名 称 以 方便 调用 。 


容 絮 的 ports 字 段 的 值 古 一 个 列表 ， 由 一 到 多 个 端口 对 象 组 成 ， 它 
的 常用 般 套 字段 包括 如 下 几 个 。 


:containerPort <integer>: 必 选 字段 ， 指 定 在 Pod 对 象 的 IP 地 址 上 暴 
露 的 容器 端口 ， 有 效 范围 为 0，65536) ;使 用 时 ， 应 该 总 是 指定 容 
絮 应 用 正常 监听 着 的 端口 。 


-name <string>: 当前 端口 的 名 称 ， 必 须 符合 IANA_SVC_NAME 规 
范 且 在 当前 Pod 内 必须 是 唯一 的 ; 此 端口 名 可 被 Service 资 源 调用 。 


:protocol: 端口 相关 的 协议 ， 其 值 仅 可 为 TCP 或 UDP， 默 认为 
TCP。 


名 提示 “可 以 通过 “kubectl explain pods.spec.containers.ports” 获 
取 ports 对 象 可 用 的 字段 列表 。 


下 面 的 资源 配置 清单 示例 (pod-example-with-port.yaml) 中 定义 的 
pod-example 指 定 了 要 又 露 容 颖 上 TCP 的 80 端 口 ， 并 将 之 命名 为 http: 


apiVersion: v1 
kind: Pod 
metadata.: 

name: pod-example 
spec: 

containers: 


- name: myapp 
image: ikubernetes/myapp:v1 
ports: 
- name: http 
containerPort: 80 
protocol: TCP 


然而 ，Pod 对 象 的 JP 地址 仅 在 当前 集群 内 可 达 ， 它 们 无 法 直接 接收 
来 目 集 群 外 部 客户 端的 请 求 流量 ， 尺 管 它们 的 服务 可 达 性 不 受 工作 市 
点 边界 的 约束 ， 但 依然 受制 于 集群 边界 。 一 个 商 单 的 解决 方案 征 通 过 
其 所 在 的 工作 节点 的 耳 地 址 和 端口 将 其 暴露 到 集群 外 部 ， 如 图 4-6 所 


示 。 
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图 4-6 ”通过 hostIP 和 hostPort 骏 露 容 器 服务 


“hostPort <integer>: 主机 端口 ， 它 将 接收 到 的 请 求 通过 NAT 机 制 
转发 至 由 containerPort 字 段 指定 的 容 右 端口 。 


:hostIP <string>: 主机 端口 要 绑 定 的 主机 卫 ， 默 认为 0.0.0.0， 即 主 
机 之 上 所 有 可 用 的 卫 地 址 ; 考虑 到 托管 的 Pod 对 象 是 由 调度 器 调度 运行 
的 ， 工 作 节 点 的 卫 地 址 难以 明确 指定 ， 因 此 此 字段 通常 使 用 默认 值 。 


需要 注意 的 是 ，hostPort 与 NodePort 类 型 的 Service 对 象 暴露 端口 的 
方式 不 同 ，NodePort 是 通过 所 有 闻 点 骏 露 容 如 服务 ， 而 hostPort 则 是 经 


由 Pod 对 象 所 在 节点 的 卫 地 址 来 进行 。 


4.2.3” 目 定义 运行 的 容 右 化 应 用 


由 Docker 镜 像 启动 容器 时 运行 的 应 用 程序 在 相应 的 Dockerfile 中 由 
ENTRYPOINT 指 令 进 行 定义 ， 传 递 给 程序 的 参数 则 通过 CMD 指 令 指 
定 ，ENTRYPOINT 指 令 不 存在 时 ，CMD 可 用 于 同时 指定 程序 及 其 参 
数 。 例 如 ， 在 某 工作 广 点 上 运行 下 面 的 命令 获取 ikubernetes/myapp: 
v1 镜像 中 定义 的 CMD 和 ENTRYPOINT， 命 令 如 下 : 


~]$ docker inspect ikubernetes/myapp:vi -f {{.Config.Cmd}} 

[nginx -g daemon off;] 

~]$ docker inspect ikubernetes/myapp:vi -f {{.Config.Entrypoint}} 
[] 


容 大 的 command 字 段 能 够 指定 不 同 于 镜像 默认 运行 的 应 用 程序 ， 
并 且 可 以 同时 使 用 args 字 上 段 进 行 参数 传递 ， 它 们 将 覆盖 镜像 中 的 默认 
定义 。 不 过 ， 如 果 仪 为 容 右 定义 了 args 字 段 ， 那 么 它 将 作为 参数 传递 
给 镜像 中 默认 指定 运行 的 应 用 程序 ， 如 果 仪 为 容 絮 定义 了 command 字 
段 ， 那么 它 将 履 六 镜像 中 定义 的 程序 及 参数 ， 并 以 无 参数 方式 运行 应 
用 程序 。 例 如 下 面 的 资源 清单 文件 将 镜像 ikubernetes/myapp: V1 的 点 
认 应 用 程序 修改 为 了 “bin/sh”， 传 递 应 用 的 参数 修改 为 了 “-c while 


true; do sleep 30; done ”: 


apiVersion: v1 
kind: Pod 
metadata: 
name: pod-with-custom-command 
spec: 
containers: 
- name: myapp 
image: alpine:latest 
command: ["/bin/sh"] 
args: ["-c","while true; do Sleep 30; done"] 


目 定 义 args， 也 是 辣 容 絮 中 的 应 用 程序 传递 配置 信息 的 常用 方式 
之 一 ， 对 于 非 云 原生 (cloud native) 的 应 用 程序 ， 这 几乎 也 是 最 简单 
的 配置 方式 。 男 一 个 常用 的 方式 是 使 用 环境 变量 。 


4.2.4 “环境 变量 


非 容 万 化 的 传统 管理 方式 中 ， 复 杂 应 用 程序 的 配置 信息 多 数 由 配 
置 文件 进行 指定 ， 用 户 可 借助 于 简单 的 文本 编辑 器 完 成 配置 管理 。 然 
而 ， 对 于 容 右 隔离 出 的 环境 中 的 应 用 程序 ， 用 户 束 不 得 不 穿 透 容器 边 
界 在 容 磺 内 进行 配置 编辑 并 进行 重 载 ， 这 种 方式 复杂 且 低 效 。 于 是 ， 
由 环境 变量 在 容 侨 启动 时 传递 配置 信息 束 成 为 一 种 备 受 青 睐 的 方式 。 


Os 这 种 方式 依赖 于 应 用 程序 支持 通过 环境 变量 进行 配置 
的 能 力 ， 否 则 ， 用 户 在 制作 Docker 镜 像 时 需要 通过 entrypoint 脚 本 完成 
环境 变量 到 程序 配置 文件 的 同步 。 


吕 Pod 对 象 中 的 容 妖 环境 变量 传递 数据 的 方法 有 两 种 :env 和 
envFrom， 这 里 重点 介绍 第 一 种 方式 ， 第 二 种 方式 将 在 介绍 ConfigMap 
和 Secret 资 源 时 进行 说 明 。 


通过 环境 变量 配置 容器 化 应 用 时 ， 需 要 在 容器 配置 段 中 榴 套 使 用 
env 字 段 ， 它 的 值 是 一 个 由 环境 变量 构成 的 列表 。 环 境 变 量 通 常 由 
name 和 value 字 段 构成 。 


name<string> : 环境 变量 的 名 称 ， 必 选 字 段 。 


value<string> : 传递 给 环境 变量 的 值 ， 通 过 $ (VAR_NAME) 引 
用 ， 逃 逸 格式 为 “$$ (VAR_NAME) ”， 默 认 值 为 空 。 


下 面 配 置 清单 中 定义 的 Pod 对 象 为 其 容 万 filebeat 传 递 了 两 个 环境 
变量 ，REDIS_HOST 定 义 了 filebeat 收 集 的 日 志 信 息 要 发 往 的 Redis 主 机 
地 址 ，LOG_LEVEL 则 定义 了 filebeat 的 日 志 级 别 : 


apiVersion: v1 
kind: Pod 
metadata: 
name: pod-with-env 
spec: 
containers: 
- name: filebeat 
image: ikubernetes/filebeat:5.6.5-alpine 
env: 


- name: REDIS_HOST 

value: db.ilinux.io:6379 
- Name: LOG_ LEVEL 

value: info 


这 些 环境 变量 可 直接 注入 容器 的 shell 环 境 中 ， 无 论 它们 是 否 真正 
到 ， 使 用 printenv 一 类 的 命令 都 能 在 容 刀 中 获取 到 所 有 环境 变量 的 
| o 


4.2.5” 共 至 市 皮 的 网 络 名 称 空间 


同一 个 Pod 对 象 的 各 容 右 均 运 行 于 一 个 独立 的 、 隔 离 的 Network 名 
称 空间 中 ， 共 享 同 一 个 网 络 协议 栈 及 相关 的 网 络 设备 ， 如 图 4-7a 所 示 。 
也 有 一 些 特殊 的 Pod 对 象 需要 运行 于 所 在 节点 的 名 称 空 间 中 ， 执 行 系统 
级 的 管理 任务 ， 例 如 查看 和 操作 节点 的 网 络 痪 源 甚 至 是 网 络 设备 等 ， 

如 图 4-7b 所 示 。 


‘| Container 


a ) 


图 4-7 Pod 对 象 的 网 络 名 称 空间 


通常 ， 以 kubeadm 部 署 的 Kubernetes 集 群 中 的 kube-apiserver、kube- 
controller-manager、kube-scheduler， 以 及 kube-proxy 和 kube-flannel 等 通 
常 都 是 第 二 种 类 型 的 Pod 对 象 。 事 实 上 ， 仪 需要 设置 spec.hostNetwork 的 
Cn 网 络 名 称 空间 的 Pod 对 象 ， 如 下 面 的 配置 
清 不 : 


apiVersion: v1 
kind: Pod 
metadata: 
name: pod-use-hostnetwork 
spec: 
containers: 
- name: myapp 
image: ikubernetes/myapp:v1 
hostNetwork: true 


将 上 面 的 配置 清单 保存 于 配置 文件 中 ， 如 pod-use- 
hostnetwork.yaml， 将 其 创建 于 集群 上 ， 并 查看 其 网 络 接 口 的 相关 属性 
信息 以 验证 它 是否 能 共享 使 用 工作 节点 的 网 络 名 称 空间 : 


~]$ kubectl apply -f pod-use-hostnetwork.yaml 


~]$ kubectl exec -it pod-use-hostnetwork -- sh 
/ # ifconfig 
etho Link encap:Ethernet Hwaddr 00:16:3E:08:1B:F4 


inet addr:172.16.0.68 Bcast:172.31.143.255 Mask:255.255.240.0 
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 


如 上 述 命 令 的 结果 显示 所 示 ， 它 打印 出 的 是 工作 节操 的 网 络 设备 
及 其 相关 的 接口 信息 。 这 就 意味 着 ，Pod 对 象 中 运行 的 容器 化 应 用 也 将 
监听 于 其 所 在 的 工作 节点 的 了 地 址 之 上， 这 可 以 通过 直接 向 
node03.ilinux.io 广 点 发 起 请 求 来 验证 : 


~]$ curl nodeQ3.ilinux.io 
Hello MyApp | Version: vi | <a href="hostname.html">Pod Name</a> 


另外 ， 在 Pod 对 象 中 时 还 可 以 分 别 使 用 spec.hostPID 和 spec.hostIPC 
来 共享 工作 节点 的 PID 和 IPC 名 称 空间 。 


4.2.6 ”设置 Pod 对 象 的 安全 上 下 文 
pod 对 象 的 安全 上 下 文 用 于 设 定 Pod 或 容器 的 权限 和 访问 控制 功 
能 ， 其 支持 设置 的 常用 属性 包括 以 下 几 个 方面 。 


:基于 用 户 ID (UID) 和 组 ID (GID) 控制 访问 对 象 ( 如 文件) 时 
的 权限 。 


以 特权 或 非特 权 的 方式 运行 。 

.通过 Linux Capabilities 为 其 提供 部 分 特权 。 
:基于 Seccomp 过 小 进程 的 系统 调用 。 

:基于 SELinux 的 安全 标签 。 

.是否 能 够 进行 权限 升级 。 


Pod 对 象 的 安全 上 下 文 定义 在 spec.securityContext 字 段 中 ， 而 容器 
的 安全 上 下 文 则 定义 在 spec.containers[].securityContext 字 段 中 ， 且 二 者 
可 骨 套 使 用 的 字段 还 有 所 不 同 。 下 面 的 配置 清单 示例 为 busybox 容 絮 定 
义 了 安全 上 下 文 ， 它 以 vid 为 1000 的 非特 权 用 户 运行 容器 ， 并 禁止 权限 


升级 : 


apiVersion: v1 
kind: Pod 
metadata: 
name: pod-with-securitycontext 
spec: 
containers: 
- name: busybox 
image: busybox 
command: ["/bin/sh","-c","sleep 86400"] 
securityContext: 
runAsNonRoot: true 
runAsUser: 1000 
allowPrivilegeEscalation: false 


将 上 面 的 配置 清单 保存 于 配置 文件 (如 pod-with- 
securitycontext.yaml 文 件 ) 中 ， 而 后 创建 于 集群 中 即 可 验证 容器 进程 的 


运行 者 身份 : 


$ kubect1l apply -f pod-with-securitycontext.yaml 


$ kubect1 exec pod-with-securitycontext -- ps aux 
PID USER TIME COMMAND 

1 1000 0:00 sleep 86400 

14 1000 0:00 ps aux 


另外， 可 设置 的 安全 上 下 文 属性 还 有 fsGroup 、seLinuxOptions 、 
supplementalGroups、sysctls、capabilities 和 privileged 等 ， 且 Pod 和 容器 
各 自 支持 的 字段 也 有 所 不 同 ， 感 兴趣 的 读者 可 按 需 对 各 属性 进行 测 


试 。 


4.3” 标 侈 己 标 俭 选 择 厦 


实践 中 ， 随 着 同类 型 资源 对 象 的 数量 越 来 越 多 ， 分 类 管理 也 变 得 
越 来 越 有 必要 : 基于 简单 月 直接 的 标准 将 资源 对 象 划 分 为 多 个 较 小 的 
分 组 ， 无 论 是 对 开发 人 员 还 是 对 系统 工程 师 来 说 ， 都 能 提升 管理 效 
率 ， 这 也 正 是 Kubemetes 标 签 (Label) 的 核心 功能 之 一 。 对 于 附带 标 
签 的 资源 对 象 ， 可 使 用 标签 选择 器 〈Label Selector) 挑选 出 符合 过 小 
条 件 的 资源 以 完成 所 需要 的 操作 ， 如 关联 、 查 看 和 删除 等 。 


4.3.1 标签 概述 


标签 是 Kubernetes 极 具 特 色 的 功能 之 一 ， 它 能 够 附加 于 Kubernetes 
的 任何 资源 对 象 之 上。 简单 来 说 ， 标 签 就 是 “ 键 值 ?类 型 的 数据 ， 它 们 
可 于 资源 创建 时 直接 指定 ， 也 可 随时 按 需 添加 于 活动 对 象 中 ， 而 后 即 
可 由 标签 选择 器 进行 匹配 度 检 查 从 而 完成 资源 挑选 。 一 个 对 象 可 拥有 
不 止 一 个 标签 ， 而 同一 个 标签 也 可 被 添加 至 多 个 资源 之 上 。 


实践 中 ， 可 以 为 资 R 尖 附加 多 个 不 同 第 度 的 标 蔚 以 实现 灵活 的 站 委 源 
分 组 管理 功能 ， 例 如 ， 版 本 标签 、 环 境 标 签 、 分 层 架 构 标 签 等 ， 用 于 
交叉 标识 同一 个 资源 所 属 的 不 同 版 本 、 环境 及 架构 层级 等 、 如 阁 4-8 所 
示 。 下 面 是 较为 常用 的 标签 。 


-版 本 标 
签 : "release": "stable"，"release": "canary", "release": "beta" 。 
-环境 标 
签 : "environment": "dev"，"environment": "qa"，"environment": "prod 
uction”" ° 
应 用 标 
Ac nh nh 11 |! 11 nh i nh nh I i mh I 11 11 11 oO 
YY: dpp: ULI，aqapp: ao，dqpp: pC, app: SC 
架构 层级 标 
签 ; ， "tier": "frontend", "tier": "backend", "tier": "cache"° 


分 区 标签 : "partition": "customerA"，"partition": "customerB"。° 


品 探 级 别 标签 : "track": "daily"，"track": "weekly"。 


「 


app: ui app: as app: pc app: sc app: os 
「 1 「 「 
Sp ] ^ccout app: pe | 
» UIpod ES rel:stable | ET telstable | 
所 全 pod od | 
S| |vrpod 
= 
3 Accout < app: as | Product 
3 Service Catalog 
至 pod pod 


图 4-8 ”多 维度 标签 使 用 示例 (图 片 来 源 : 《Kubernetes in action》 ) 
标签 中 的 键 名 称 通 常 由 键 前缀 和 键 名 组 成 ， 其 中 键 前 缀 可 选 ， 其 
格式 形 如 “KEY_PREFIX/KEY_NAME”。 键 名 至 多 能 使 用 63 个 字符 ， 可 
使 用 字母 、 数 字 、 连 接 号 (-) 、 下 划 线 (_) 、 点 号 (.) 等 字符 ， 并 
且 只 能 以 字母 或 数字 开头 。 键 前 缀 必须 为 DNS 子 域名 格式 ， 且 不 能 超 
过 253 个 字符 。 省 略 键 前 缀 时 ， 键 将 被 视 为 用 户 的 私有 数据 ， 不 过 由 
Kubernetes 系 统 组 件 或 第 三 方 组 件 上 自动 为 用 户 资 源 添 加 的 键 必 须 使 用 键 
前 缀 ， 而 “kubernetes.io/ 前 缀 则 预 留 给 Kubernetes 的 核心 组 件 使 用 。 


标签 中 的 键 值 必须 不 能 多 于 63 个 字符 ， 它 要 么 为 空 ， 要 么 是 以 字 


母 或 数字 开头 及 结尾 ， 且 中 间 仅 使 用 了 字母 、 数 字 、 连 接 号 (-) 、 下 
划 线 (_) 或 点 号 〈.) 等 字符 的 数据 。 


@ 实践 中 ， 建 议 键 名 及 键 值 能 做 到 “ 见 名 知 义 ”， 且 尽 可 
能 保持 简单 


4 .32 管理 资源 标签 VY 7 


创建 资源 时 ， 可 直接 在 其 metadata 中 骸 套 使 用 “labels” 字 段 以 定义 
要 附加 的 标签 项 。 例 如 ， 下 面 的 Pod 资 源 清 单 文 件 示 例 pod-with- 
labels.yaml 中 使 用 了 两 个 标签 env=qa 和 tier=frontend: 


apiVersion: v1 
kind: Pod 
metadata: 
name: pod-with-labels 
labels: 
env: qa 
tier: frontend 
spec: 
containers: 
- name: myapp 
image: ikubernetes/myapp:v1 


基于 此 资源 清单 创建 出 定义 的 Pod 对 象 之 后 ， 即 可 在 “kubectl get 
pods” 命 令 中 使 用 “--show-labels” 选 项 ， 以 额外 显示 对 象 的 标签 信息 : 


~]$ kubectl1 apply -f pod-with-labels.yaml 
pod "pod-with-labels" created 
~]$ kubectl1 get pods --show-labels 


NAME READY STATUS RESTARTS AGE LABELS 
pod-example 1/1 Running 0 3h <none> 
pod-with-labels 1/1 Running 0 13s env=qa, tier=frontend 


标签 较 多 上 时， 在 “kubectl get pods” 命 令 上 使 用 “-L key1， 
key2, ...” 选项 可 指定 显示 有 夺 符 定 吕 的 标 空 信息。 例如 ， 仅 显示 各 
pods 之 上 的 以 env 和 tier 为 键 名 的 标签 


~]$ kubect1 get pods -L env,tier 


NAME READY STATUS RESTARTS AGE ENV TIER 
pod-example 1/1 Running 2 3h 
pod-with-labels 1/1 Running 0 5m da frontend 


“kubectl label”* 命 令 可 以 直接 管理 活动 对 象 的 标签 ， 以 按 需 进行 添 
加 或 修改 等 操作 。 例 如 ， 为 pod-example 添 加 env=production 标 签 


~]$ kubect1 label pods/pod-example env=production 
pod "pod-example" labeled 


不 过 ， 对 于 已 经 附带 了 指定 键 名 的 标签 ， 使 用 “kubectl label” 为 其 
设 定 新 的 键 值 时 需要 为 命令 同时 使 用 “--overwrite” 命 令 以 强制 履 盖 原 有 
的 键 值 。 例 如 ， 将 pod-with-labels 的 env 的 值 修改 为 “testing”: 


~]$ kubect1 label pods/pod-with-labels env=testing --overwrite 
pod "pod-with-labels" labeled 


用 户 寿 期望 对 某 标签 之 下 的 资源 集合 执行 某 类 操作 ， 例 如 ， 查 看 
或 删除 等 ， 则 需要 先 使 用 “标签 选择 占 ” 挑 选 出 满足 条 件 的 资源 对 象 。 


4.3.3 ”标签 选择 需 


标签 选择 絮 用 于 表达 标签 的 查询 条 件 或 选择 标准 ，Kubernetes APIT 
目前 支持 两 个 选择 器 : 基于 等 值 关系 (equality-based) 以 及 基于 集合 
关系 (set-based) 。 例 如 ，env=production 和 env! =qa 是 基于 等 值 关 系 
人 选择 器 ， 而 tier in (frontend，backend) 则 是 基于 集合 关系 的 选择 

。 另 外， 使 用 标签 选择 需 时 还 将 遭 循 以 下 逻辑 。 


1) 同时 指定 的 多 个 选择 器 之 间 的 逻辑 关系 为 “与 ”操作 。 
2) 使 用 空 值 的 标签 选择 器 意味 着 每 个 资源 对 象 都 将 被 选中 。 
3) 空 的 标签 选择 器 将 无 法 选 出 任何 资源 。 
基于 等 值 天 系 的 标签 选择 器 的 可 用 操作 符 有 “=”==” 和 “! =” 三 
种 ， 其 中 前 两 个 意义 相同 ， 痢 表示 “等 值 ”关系 ， 最 后 一 个 表示 “不 


等 ”大 系 。“kubect] get” 命 令 的 “-]* 选 项 能 够 指定 使 用 标签 选择 右 ， 例 
如 ， 显 示 键 名 env 的 值 不 为 qa 的 所 有 Pod 对 象 : 


~]$ kubect1 get pods -1 "env!=qa" -L env 

NAME READY STATUS RESTARTS AGE ENV 
pod-example 1/1 Running 2 4h production 
pod-with-labels 1/1 Running 0 40m testing 


再 例如 ， 显 示 标 签 键 名 env 的 值 不 为 ga， 且 标签 键 名 tier 的 值 为 
frontend 的 所 有 Pod 对 象 : 


~]$ kubectl1 get pods -1 "env!=qa,tier=frontend" -L env,tier 


NAME READY STATUS RESTARTS AGE ENV TIER 
pod-with-labels 1/1 Running 0 43m testing frontend 
基于 集合 关系 的 标签 选择 器 支持 in、notin 和 exists 三 种 操作 符 ， 它 


们 的 使 用 和 们 及 义 具体 如 下 。 


KEYin (VALUE1，VALUE2，...) : 指定 的 键 名 的 值 存 在 于 给 
定 的 列表 中 即 满足 条 件 。 


-KEY notin (VALUE1，VALUE2，...) : 指定 的 键 名 的 值 不 存在 
于 给 定 的 列表 中 即 满足 条 件 。 


KEY: 所 有 存在 此 键 名 标签 的 资源 。 
`! KEY: 所 有 不 存在 此 键 名 标签 的 资源 。 
例如 ， 显 示 标 签 键 名 env 的 值 为 production 或 dev 的 所 有 Pod 对 象 : 


~]$ kubectl get pods -1 "env in (production,dev)" -L env 
NAME READY STATUS RESTARTS AGE ENV 
pod-example 1/1 Running 2 4h production 


再 如 ， 列 出 标签 键 名 env 的 值 为 production 或 dev， 且 不 存在 键 名 为 
tier 的 标签 的 所 有 Pod 对 象 : 


~]$ kubectl1 get pods -1 'env in (production,dev),!tier' -L env,tier 
NAME READY STATUS RESTARTS AGE ENV TIER 
pod-example 1/1 Running 2 4h production 


fy 注意 ”为 了 避免 shell 解 释 器 解析 叹 号 (1 ) ， 必 须要 为 此 类 
表达 式 使 用 单 引号 。 


此 外 ，Kubernetes 的 诸多 资源 对 象 必 须 以 标签 选择 絮 的 方式 关联 
到 Pod 资 源 对 象 ， 例 如 Service、Deployment 和 和 ReplicaSet 类 型 的 资源 
和 等， 它们 在 spec 字 段 中 骸 套 使 用 散人 套 的 “selector”" 字 段 ， 通 
过 “matchLabels” 来 指定 标签 选择 器 ， 有 的 甚至 还 支持 使 
用 “matchExpressions” 构 造 复杂 的 标签 选择 机 制 。 


matchLabels: 通过 直接 给 定 键 值 对 来 指定 标签 选择 器 。 


-matchExpressions: 基于 表达 式 指定 的 标签 选择 恬 列 表 ， 每 个 选择 
器 都 形 如 “{key: KEY_NAME, operator: OPERATOR ，values: 
[VALUE1，VALUE2，...]}”， 选 择 硕 列表 间 为 "逻辑 与 ?关系 ; 使 用 In 
或 Notm 探 作 符 时 ， 其 values 不 强制 要 求 为 非 衬 的 字符 串 列 表 ， 而 使 用 
Exists 或 DostNotExist 时 ， 其 values 必 须 为 空 。 


下 面 所 示 的 资源 清单 片断 是 一 个 示例 ， 它 同时 定义 了 两 类 标签 选 


-3 日 
择 屁 : 
selector: 
matchLabels: 
component: redis 
matchExpressions: 


- {key: tier, operator: In, values: [cache]} 
- {key: environment, operator: Exists, values:} 


标签 巍 予 了 Kubernetes 灵 活 操 作 俯 源 对 象 的 能 力 ， 它 也 是 Service 
和 Deployment 等 核心 资源 类 型 得 以 实现 的 基本 前 提 。 


4.3.4 ”Pod 斑点 选择 硕 nodeSelector 


pod 节 点 选择 器 是 标签 及 标签 选择 器 的 一 种 应 用 ， 它 能 够 让 Pod 对 
象 基于 集群 中 工作 节点 的 标签 来 挑选 倾向 运行 的 目标 节点 。 


Kubernetes 的 kube-scheduler 守 护 进 程 负责 在 各 工作 节点 中 基于 系 
统 资 源 的 可 用 性 等 标签 挑选 一 个 来 运行 竺 创建 的 Pod 对 象 ， 默 认 的 调 
度 器 是 default-scheduler。Kubernetes 可 将 所 有 工作 节点 上 的 各 系统 资源 
抽象 成 资源 池 统 一 分 配 使 用 ， 因 此 用 户 无 须 关 心 Pod 对 象 的 具体 运行 
位 置 也 能 良好 工作 。 不 过 ， 事 情 总 有 例外 ， 比 如 仅 有 部 分 节点 拥有 被 
Pod 对 象 依赖 到 的 特殊 便 件 设备 的 情况 ， 如 GPU 和 SSD 等 。 即 便 如 此 ， 
用 户 也 不 应 该 静态 指定 Pod 对 象 的 运行 位 置 ， 而 是 让 scheduler 基 于 标签 
和 标签 选择 需 为 Pod 挑 选 匹 配 的 工作 和 点 。 


Pod 对 象 的 spec.nodeSelector 可 用 于 定义 太 点 标签 选择 右 ， 用 户 事 
先 为 特定 部 分 的 Node 资 源 对 象 设 是 好 标签 ， 而 后 配置 Pod 对 象 通过 市 
点 标签 选择 器 进行 匹配 检测 ， 从 而 完成 节点 亲 和 性 调度 。 


为 Node 资 源 对 象 附 加 标签 的 方法 同 Pod 资 源 ， 使 用 “kubectl label 
nodes/INODE” 命 令 即 可 。 例 如， 可 为 node01.ilinux.io 和 node03.ilinux.io 
斑点 设置 “disktype=ssd” 标 签 以 标识 其 拥有 SSD 设 备 : 


~]$ kubectl1 label nodes node01.ilinux.io disktype=ssd 
node "node01.ilinux.io" labeled 
~]$ kubectl1 label nodes nodeQ3.ilinux.io disktype=ssd 
node "node03.ilinux.io" labeled 


查看 具有 键 名 SSD 的 标签 的 Node 资 源 : 


~]$ kubect1 get nodes -1 'disktype' -L disktype 


NAME STATUS ROLES AGE VERSION DISKTYPE 
node01.ilinux.io Ready <none> 15d V1.12.1 ssd 
node03.ilinux.io Ready <none> 15d V1.12.1 ssd 


如 果 某 Pod 资 源 需要 调度 至 这 些 具 有 SSD 设 备 的 厄 点 之 上 ， 那 么 只 
需要 为 其 使 用 spec.nodeSelector 标 签 选 择 器 即 可 ， 例 如 下 面 的 资源 清单 


文件 pod-with-nodeselectoryaml 示 例 : 


apiVersion: v1 
kind: Pod 
metadata: 
name: pod-with-nodeselector 
labels: 
env: testing 
spec: 
containers: 
- name: myapp 
image: ikubernetes/myapp:v1 
nodeSelector: 
disktype: ssd 


将 如 上 资源 清单 中 定义 的 Pod 资 源 创建 于 集群 中 ， 通 过 查看 其 i 
行 的 结 点 即 可 判定 调度 效果 。 


另外 ， 动 手 测试 和 查看 过 节点 标签 的 读者 或 许 已 经 注意 到 了 ， 
群 中 的 每 个 节点 默认 已 经 附 融 了 多 个 标签 ， ee en 、 
beta.kubernetes.io/os 和 beta.kubernetes.io/arch 等 。 这 些 标签 也 可 以 直接 
由 nodeSelector 使 用 ， 尤 其 是 希望 将 Pod 调 度 至 某 特定 广 点 时 ， 可 以 使 
用 kubernetes.io/hostname 直 接 绑 定 至 相应 的 主机 即 可 。 不 过 ， 这 种 绑 定 
至 特定 主机 的 需求 还 有 一 种 更 为 简单 的 实现 方式 ， 即 使 用 
spec.nodeName 字 段 直接 指定 目标 节点 。 
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4.4 资源 注解 


除了 标签 (label) 之 外 ，Pod 与 其 他 各 种 资源 还 能 使 用 资源 注解 
(annotation) 。 与 标签 类 似 ， 注 解 也 是 “ 键 值 类 型 的 数据 ， 不 过 它 不 
能 用 于 标签 及 挑选 Kubernetes 对 象 ， 仅 可 用 于 为 资源 提供 “元 数据 ” 信 
息 。 另 外， 注解 中 的 元 数据 不 受 字符 数量 的 限制 ， 它 可 大 可 小 ， 可 以 
为 结构 化 或 非 结 构 化 形式 ， 也 支持 使 用 在 标签 中 禁止 使 用 的 其 他 字 
符 。 


资源 注解 可 由 用 户 手动 添加 ， 也 可 由 工具 程序 目 动 附加 并 使 用 它 
们 。 在 Kubernetes 的 新 版 本 中 alpha 或 beta 阶 段 ) 为 某 资源 引入 新 字段 
时 ， 常 以 注解 的 方式 提供 ， 以 避免 其 增删 等 变动 对 用 户 带 来 困扰 ， 一 
旦 确定 支持 使 用 它们 ， 这 些 新 增 字 段 束 将 再 引入 到 资源 中 并 淘汰 相关 
的 注解 。 另 外 ， 为 资源 添加 注解 也 可 让 其 他 用 户 快速 了 解 资源 的 相关 
信息 ， 例 如 其 创建 者 的 身份 等 。 以 下 为 常用 的 场景 案例 。 

:由 声明 式 配 置 层 (如 apply 命 令 ) 管理 的 字段 : 将 这 些 字段 定义 为 
注解 有 助 于 识别 由 服务 絮 或 客户 端 设 定 的 默认 值 、 系 统 目 动 生 成 的 字 
段 以 及 由 目 动 伸缩 系统 生成 的 字段 。 


构建、 发 行 或 镜像 相关 的 信息 ， 例 如 ， 时 间 崔 、 发 行 ID、Git 分 
文 、PR 号 码 、 镜 像 哈 硕 及 仓库 地 址 等 。 


- 指 同 日 志 、 监 控 、 分 析 或 审计 仓库 的 指针 。 


由 客户 端 库 或 工具 程序 生成 的 用 于 调试 目的 的 信息 : 如 名 称 、 版 
本 、 构 建 信息 等 。 


用户 或 工具 程序 的 来 源 地 信息 ， 例 如 ， 来 目 其 他 生态 系统 组 件 的 
相关 对 和 象 的 url 。 


. 轻 量 化 滚动 升级 工具 的 元 数据 ， 如 config 及 checkpoints。 


-相关 人 员 的 电话 号 码 等 联系 信息 ， 或 者 指 同 类 似 信息 的 可 寻 址 的 
目录 条 目 ， 如 网 站 站 点 。 


4.4.1 ”查看 资源 注解 


“kubectl getro yaml” 和 “kubectl describe”* 命 令 均 能 显示 资源 的 注解 
信息 。 例 如 下 面 的 命令 显示 的 pod-example 的 注解 信息 .: 


~]$ kubectl1 describe pods pod-example 


Name : pod-example 

Namespace: default 

Node: nodeQ02.ilinux.i0o/172.16.0.67 
Start Time: Mon, 26 Feb 2018 18:40:53 +0800 
Labels: env=production 


Annotations: kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"v 
1","kind":"Pod", "metadata":{"annotations":{},"name":"pod-example", "namespa 
ce":"default"},"spec":{"containers":[{"image":"ikubernetes/m.. 

Status: Running 


pod-example 此 前 由 声明 式 配 置 命令 apply 创 建 ， 因 此 它 在 注解 中 保 
存 了 如 上 的 相关 信息 以 便 在 下 次 资源 变动 时 进行 版 本 对 比 。 


4.4.2 ”管理 资源 注解 


annotations 可 在 资源 创建 时 使 用 “metadata.annotations” 字 上 段 指定 
也 可 随时 按 需 在 活动 的 资源 上 使 用 “kubectl annotate” 命 令 进行 附加 。 例 
如 ， 为 pod-example 重 新 进行 注解 : 


~]$ kubectl annotate pods pod-example ilinux.io/created-by="cluster admin" 
pod "pod-example" annotated 


查看 生成 的 注解 信息 : 


~]$ kubectl1 describe pods pod-example | grep "Annotations" 
Annotations: ilinux.io/created-by=cluster admin 


0 需要 在 资源 创建 时 的 清单 中 指定 ， 那 么 使 用 类 似 如 下 的 方式 
品 


apiVersion: v1 
kind: Pod 
metadata: 
name: pod-example 
annotations: 
ilinux.io/created-by: cluster admin 
spec: 


4.5 Pod 对 象 的 生命 周期 


Pod 对 象 自从 其 创建 开始 至 其 终止 退出 的 时 间 范 围 称 为 其 生命 周 
期 。 在 这 段 时 间 中 ，Pod 会 处 于 多 种 不 同 的 状态 ， 并 执行 一 些 操 作 ; 
其 中 ， 创 建 主 容器 (main container) 为 必需 的 操作 ， 其 他 可 选 的 操作 
还 包括 运行 初始 化 容器 (init container) 、 容 器 局 动 后 钩子 (post start 
hook) 、 容 器 的 存活 性 探测 (iveness probe) 、 就 绪 性 探测 (readiness 
probe) 以 及 容器 终止 前 钧 子 (pre stop hook) 等 ， 这 些 操作 是 否 执 行 
则 取决 于 Pod 的 定义 ， 如 图 4-9 所 示 。 


4.5.1 Pod 的 相位 


无 论 是 类 似 前 面 儿 节 中 的 由 用 户 手 动 创建 ， 还 是 通过 Deployment 
i Pod 对 象 总 是 应 该 处 于 其 生命 进程 中 以 下 几 个 相位 
phase = 


.Pending: API Server 创 建 了 Pod 资 源 对 象 并 已 存 入 etcd 中 ， 但 它 尚 
未 被 调度 完成 ， 或 者 仍 处 于 从 仓库 下 载 镜 像 的 过 程 中 。 


.Running: Pod 已 经 被 调 度 至 某 廊 点 ， 并 且 所 有 容器 都 已 经 被 
kubelet 创 建 完 成 。 


:Succeeded: Pod 中 的 所 有 容器 都 已 经 成 功 终止 并 且 不 会 被 重 局 。 


.Failed: 所 有 容 句 都 已 经 终止 ,但 至 少 有 一 个 容器 终止 失败 ， 即 容 
絮 运 回 了 非 0 值 的 退出 状态 或 已 经 锌 系统 终止 。 
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或 Pod 对 和 象 


> 


time (sec) 


图 4-9 Pod 的 生命 周期 (图 片 来 源 ，https://blog.openshift.com) 


:Unknown: API Server 无 法 正常 获取 到 Pod 对 象 的 状态 信息 ， 
是 由 于 其 无 法 与 所 在 工作 和 点 的 kubelet 通 


4.5.2 ”Pod 的 创建 过 程 


Pod 是 Kubernetes 的 基础 单元 ， 理 解 它 的 创建 过 程 对 于 了 解 系统 运 
作 大 有 神 益 。 图 4-10 描 述 了 一 个 Pod 资 源 对 象 的 典型 创建 过 程 。 


1) 用 户 通过 kubectl 或 其 他 API 客 户 端 提交 Pod Spec 给 API Server 。 


2) API Server 党 试 着 将 Pod 对 象 的 相关 信息 存 入 etcd 中 ， 待 写 入 操 
作 执 行 完成 ，API Server 即 会 返回 确认 信息 至 客户 端 。 


3) API Server 开 始 反 映 etcd 中 的 状态 变化 。 


4) 所 有 的 Kubernetes 组 件 均 使 用 “watch”* 机 制 来 跟踪 检查 API Server 
上 的 相关 的 变动 。 


5) kube-scheduler (调度 器 ) 通过 其 “watcher* 觉 察 到 API Server 创 
建 了 新 的 Pod 对 象 但 尚未 绑 定 至 任何 工作 节点 。 


6) kube-scheduler 为 Pod 对 象 挑选 一 个 工作 节点 并 将 结果 信息 更 新 
至 API Server 。 


create Pod 


write 


watch(new pod) 
bind pod 


write 


~ 


watch(bound pody Bo 
ocker run 


'update pod status: | 
wiite 


ee ee > 


图 4-10 ”Pod 资源 对 象 创建 过 程 (图 片 来 源 :， https://blog.heptio.com/ ) 


7) 调度 结果 信息 由 API Server 更 新 至 etcd 存 储 系统 ， 而 且 API 
Server 也 开始 反映 此 Pod 对 象 的 调度 结果 。 


8) Pod 被 调度 到 的 目标 工作 节点 上 的 kubelet 和 党 试 在 当前 节点 上 调 
用 Docker 局 动容 器 ， 并 将 容器 的 结果 状态 回 送 至 API Server。 


9) API Server 将 Pod 状 态 信 息 存 入 etcd 系 统 中 。 


10) 在 etcd 确 认 写 入 操作 成 功 完成 后 ，API Server 将 确认 信息 发 送 
至 相关 的 kubelet， 事 件 将 通过 它 被 接受 。 


4.5.3 “Pod 生 命 周 期 中 的 重要 行为 


除了 创建 应 用 容器 〈 主 容器 及 其 辅助 容器 ) 之 外 ， 用 户 还 可 以 为 
Pod 对 象 定 义 其 生命 周期 中 的 多 种 行为 ， 如 初始 化 容 磊 、 存 活性 探测 
及 吕 绪 性 探测 等 。 


1. 初 始 化 容器 

初始 化 容器 (init container) 即 应 用 程序 的 主 容器 启动 之 前 要 运行 
J 常用 于 为 主 容器 执行 一 些 预 置 操作 ， 它 们 具有 两 种 典型 特 
征 法 


1) 初始 化 容器 必须 运行 完成 直至 结束 ， 若 某 初 始 化 容器 运行 失 
败 ， 那 么 Kubernetes 需 要 重启 它 直 到 成 功 完成 。 


2) 每 个 初始 化 容器 都 必须 按 定义 的 顺序 串 行 运行 


O 注意 ”如果 Pod 的 spec.restartPolicy 字 段 值 为 *Never”， 那 么 
运行 失败 的 初始 化 容 句 不 会 被 重启 。 


有 不 少 场景 都 需要 在 应 用 容 右 局 动 之 前 进行 部 分 初始 化 操作 ， 例 
如 ， 等 待 其 他 关联 组 件 服务 可 用 、 基 于 环境 变量 或 配置 模板 为 应 用 程 
序 生成 配置 文件 、 从 配置 中 心 获取 配置 等 。 初 始 化 容 右 的 典型 应 用 需 
求 具体 包含 如 下 几 种 。 


1) 用 于 运行 特定 的 工具 程序 ， 出 于 安全 等 方面 的 原因 ， 这 些 程序 
不 适 于 包 舍 在 主 容 需 镜像 中 。 


2) 提供 主 容器 镜像 中 不 具备 的 工具 程序 或 自 定义 代码 。 


3) 为 容器 镜像 的 构建 和 部 署 人 员 提 供 了 分 离 、 独 立 工作 的 途径 ， 
使 得 他 们 不 必 协 同 起 来 制作 单个 镜像 文件 。 


4) 初始 化 容器 和 主 容器 处 于 不 同 的 文件 系统 视图 中 ， 因 此 可 以 分 
别 安全 地 使 用 敏感 数据 ， 例 如 Secrets 资 源 。 


5) 初始 化 容器 要 先 于 应 用 容器 串 行 启动 并 运行 完成 ， 因 此 可 用 于 
延 后 应 用 容器 的 启动 直至 其 依赖 的 条 件 得 到 满足 。 


Pod 资 源 的 “spec.initContainers” 字 段 以 列表 的 形式 定义 可 用 的 初始 
容 骨 ， 其 仍 套 可 用 字段 类 似 于 “spec.containers”。 下 面 的 资源 清单 仅 是 
0 ， 读 者 可 目 行 创建 并 观察 初始 化 容 恬 的 相 


apiVersion: v1 
kind: Pod 
metadata: 
name: myapp-pod 
labels: 
app: myapp 
spec: 
containers: 
- name: myapp-container 
image: ikubernetes/myapp:v1 
InitContainers : 
- name: init-something 
image: busybox 
command: ['sh', '-c', 'sleep 10°'] 


2. 生 命 周期 钩子 函数 


生命 周期 钩子 函数 (lifecycle hook) 是 编程 语言 (如 Angular) 中 
常用 的 生命 周期 管理 的 组 件 ， 它 实现 了 程序 运行 周期 中 的 关键 时 刻 的 
可 见 性 ， 并 赋予 用 户 为 此 采取 某 种 行动 的 能 力 。 类 似 地 ， 容 颖 生命 周 
期 钧 子 使 它 能 够 感知 其 自身 生命 周期 管理 中 的 事件 ， 并 在 相应 的 时 刻 
到 来 时 运行 由 用 户 指定 的 处 理 程序 代码 。Kubernetes 为 容 需 提供 了 两 
种 生命 周期 钩子 。 


:postStart 于 容 融 创建 完成 之 后 立即 运行 的 钩子 处 理 器 
(handler) ， 不 过 Kubemetes 无 法 人 确保 它 一 定 会 于 容器 中 的 
ENTRYPOINT 之 前 运行 。 


:preStop: 于 容器 终止 操作 之 前 立即 运行 的 钩子 处 理 右 ， 它 以 同步 
的 方式 调用 ， 因 此 在 其 完成 之 前 会 阻塞 删除 容 夯 的 操作 的 调用 。 


钩子 处 理 器 的 实现 方式 有 “Exec" 和 “HTTP" 两 种 ， 前 一 种 在 钩子 事 
件 触 发 时 直接 在 当前 容 絮 中 运行 由 用 户 定义 的 命令 ， 后 一 种 则 是 在 当 
前 容器 中 向 某 URL 发 起 HTTP 请 求 。 


postStart 和 preStop 处 理 需 定义 在 容器 的 spec.lifecycle 航 套 字 段 中 ， 
其 使 用 方法 如 下 面 的 资源 清单 所 示 ， 读 者 可 目 行 创建 相关 的 Pod 资 源 
对 象 ， 并 验证 其 执行 结果 : 


apiVersion: v1 
kind: Pod 
metadata: 

name: lifecycle-demo 

spec: 

containers: 

- Name: lifecycle-demo-container 
image: ikubernetes/myapp:v1 
lifecycle: 

postStart: 
exec: 
command: ["/bin/sh","-c","echo 'lifecycle hooks handler' > /usr/share/ 
nginx/html/test.html"] 


3. 容 需 探 测 


容器 探测 (container probe) 是 Pod 对 象 生 命 周 期 中 的 一 项 重要 的 
日 常任 务 ， 它 是 kubelet 对 容 灵 周 期 性 执行 的 健康 状态 诊断 ， 诊 断 操作 
由 容 希 的 处 理 屡 (handler) 进行 定义 。Kubernetes 支 持 三 种 处 理 器 用 
于 Pod 探 测 。 


:ExecAction: 在 容 需 中 执行 一 个 命令 ， 并 根据 其 返回 的 状态 码 进 
行 疹 断 的 操作 称 为 Exec 探 测 ， 状态 码 为 0 表示 成 功 ， 否 则 即 为 不 健康 状 
-TCPSocketAction: 通过 与 容 髓 的 某 TCP 端 口 芝 试 建立 连接 进行 诊 
汤 ， 端 口 能 够 成 功 打 开 即 为 正常 ， 否 则 为 不 健康 状态 。 


.HTTPGetAction: 通过 向 容器 IP 地 址 的 某 指 定 端口 的 指定 path 发 起 
HTTP GET 请 求 进行 诊断 ， 啊 应 码 为 2xx 或 3xx 时 即 为 成 功 ， 否 则 为 失 
败 。 


任何 一 种 探测 方式 都 可 能 存在 三 种 结果 : “Success”( 成 
功 ) 、“Failure” (失败 ) 或 “Unknown”( 未 知 ) ， 只 有 第 一 种 结果 表 
示 成 功 通过 检测 。 


:kubelet 可 在 活动 容 絮 上 执行 两 种 类 型 的 检测 : 存活 性 检测 
(livenessProbe) 和 就 绪 性 检测 (readinessProbe) 。 


.存活 性 检测 : 用 于 判定 容器 是 否 处 于 “运行 ” (Running) 状态 ; 
一 旦 此 类 检测 未 通过 ，kubelet 将 杀 死 容 絮 并 根据 其 restartPolicy 决 定 是 
否 将 其 重启 ; 未 定义 存活 性 检测 的 容 絮 的 默认 状态 为 “Success”。 瑞 绪 
性 检测 : 用 于 判断 容器 是 否 准 备 就 绪 并 可 对 外 提供 服务 ;未 通过 检测 
的 容器 意味 着 其 尚未 准备 就 绪 ， 端 点 控制 器 〈 如 Service 对 象 ) 会 将 其 
IP 从 所 有 匹配 到 此 Pod 对 象 的 Service 对 象 的 端点 列表 中 移 除 ; 检测 通过 
之 后 ， 会 再 次 将 其 IP 添 加 至 端点 列表 中 。 


名 提示 存活 性 检测 和 就 绪 性 检测 相关 的 话题 在 后 文 的 革 市 
中 还 会 有 进一步 的 介绍 。 


4.5.4” 容 希 的 重 局 案 略 


容 需 程序 发 生 朋 总 或 容器 申请 超出 限制 的 资源 等 原因 都 可 能 会 导 
致 Pod 对 象 的 终止 ， 此 时 是 否 应 该 重建 该 Pod 对 象 则 取决 于 其 重启 策略 
(restartPolicy) 属性 的 定义 。 


1) Always: 但 几 Pod 对 象 终止 就 将 其 重启 ， 此 为 默认 设 定 。 
2) OnFailure: 仅 在 Pod 对 象 出 现 错误 时 方才 将 其 重启 。 
3) Never: 从 不 重启 。 


需要 注意 的 是 ，restartPolicy 适 用 于 Pod 对 象 中 的 所 有 容器 ， 而 且 
它 仅 用 于 控制 在 同一 节点 上 重新 启动 Pod 对 象 的 相关 容器 。 首 次 需要 
重启 的 容 姻 ， 将 在 其 需要 时 立即 进行 重启 ， 随 后 再 次 需要 重启 的 操作 
将 由 kubelet 延 迟 一 段 时 间 后 进行 ， 且 反复 的 重启 操作 的 延迟 时 长 依次 
为 10 秒 、20 秒 、40 秒 、80 秒 、160 秒 和 300 秒 ，300 秒 是 最 大 延迟 时 长 。 
事实 上 , 一 旦 绑 定 到 一 个 节点 ，Pod 对 象 将 永远 不 会 彼 重 新 绑 定 到 男 
一 个 节点 ， 它 要 么 被 重 局 ， 要 么 终止 ， 直 到 下 点 发 生 故 障 或 被 删除 。 


4.5.5 “Pod 的 终止 过 程 


Pod 对 象 代表 了 在 Kubernetes 集 群 节点 上 运行 的 进程 ， 它 可 能 曾 用 
于 处 理 生产 数据 或 回 用户 提供 服务 等 ， 于 是 ， 当 Pod 本 和 映 不 再 具有 存在 
的 价值 时 ， 如 何 将 其 优雅 地 终止 就 显得 尤为 重要 了 ， 而 用 户 也 需要 能 
够 在 正常 提交 删除 探 作 后 可 以 获知 其 何 时 开始 终止 并 最 终 完 成 。 控 作 
中 ， 当 用 户 提 交 删 除 请 求 之 后 ， 系 统 就 会 进行 强制 删除 操作 的 宽 限 期 
倒计时 ， 并 将 TERM 信息 发 送 给 Pod 对 象 的 每 个 容器 中 的 主 进程 。 窝 限 
期 倒计时 结束 后 ， 这 些 进程 将 收 到 强制 终止 的 KILL 信 号 ，Pod 对 和 象 随即 
也 将 由 API Server 删 除 。 如 果 在 等 待 进程 终止 的 过 程 中 ，kubelet 或 容 需 
管理 器 发 生 了 重启 ， 那 么 终止 操作 会 重新 获得 一 个 满 额 的 删除 宽 限 期 
并 重新 执行 删除 操作 。 


如 图 4-11 所 示 ， 一 个 典型 的 Pod 对 象 终止 流程 具体 如 下 。 
1) 用 户 发 送 删 除 Pod 对 象 的 命令 。 


2) API 服 务 器 中 的 Pod 对 象 会 随 着 时 间 的 推移 而 更 新 ， 在 宽 限期 内 
(默认 为 30 秒 ，，Pod 被 视 为 “dead”。 


3) 将 Pod 标 记 为 “Terminating” 状 态 。 


4) (与 第 3 步 同 时 运行 ) kubelet 在 监控 到 Pod 对 象 转 
为 “Terminating” 状 态 的 同时 启动 Pod 天 闭 过 程 。 


5) (与 第 3 步 同 时 运行 ) 端点 控制 器 监控 到 Pod 对 象 的 关闭 行为 时 
将 其 从 所 有 匹配 到 此 端点 的 Service 资 源 的 端点 列表 中 移 除 。 


API Server etcd kubelet docker Endpoint 
controller 
1 


delete Pod 1 1 
-一 


1 
1 
1 
set grace 1 
1 
period 有 
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1 
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1 
1 

1 

1Temove pod 

1 个 dpoi 

1 ftom endpoint 
1 of all services 


watch(Expiry oflgrace period) 


i i 
Immediataideletion of pod 1 


<--------f------------------- 


1 
| deletion of ! : 
| object from etcd | 1 
一 一 一 一 一 一 一 一 全 1 

1 


图 4-11 Pod 的 终止 过 程 


6) 如 果 当 前 Pod 对 象 定 义 了 preStop 钧 子 处 理 器 ， 则 在 其 标记 
为 “terminating” 后 即 会 以 同步 的 方式 启动 执行 ， 如 若 宽 限期 结束 后 ， 
人 ， 则 第 2 步 会 被 重新 执行 并 额外 获取 一 个 时 长 为 2 
少 的 小 寓 限 期 。 


7) Pod 对 象 中 的 容器 进程 收 到 TERM 信号。 


8) 宽 限 期 结束 后 ， 若 存在 任何 一 个 仍 在 运行 的 进程 ， 那 么 Pod 对 
象 即 会 收 到 SIGKILL 信 号 。 


9) Kubelet 请 求 API Server 将 此 Pod 资 源 的 宽 限 期 设置 为 0 从 而 完成 
删除 操作 ， 它 变 得 对 用 户 不 再 可 见 。 


默认 情况 下 ， 所 有 删除 操作 的 宽 限 期 都 是 30 秒 ， 不 过 ，kubect 
delete 命 令 可 以 使 用 “--grace-period=<seconds>” 选 项 目 定义 其 时 长 ， 大 使 
用 0 值 则 表示 直接 强制 删除 指定 的 资源 ， 不 过 ， 此 时 需要 同时 为 命令 使 
用 “--force” 选 项 。 


4.6 ”Pod 存 活性 探测 


有 不 少 应 用 程序 长 时 间 持 续 运行 后 会 逐渐 转 为 不 可 用 状态 ， 并且 
仅 能 通过 重启 操作 恢复 ，Kubernetes 的 容器 存活 性 探测 机 制 可 发 现 诸 
如 此 类 的 问题 ， 并 依据 探测 结果 结合 重启 策略 触发 后 续 的 行为 。 存 活 
性 探测 是 隶属 于 容器 级 别 的 配置 ，kubelet 可 基于 它 判定 何 时 需要 重启 
一 个 容 兹 。 


Pod spec 为 容 絮 列表 中 的 相应 容器 定义 其 专用 的 探 针 (存活 性 探 
测 机 制 ) 即 可 启用 存活 性 探测 。 目 前 ，Kubernetes 的 容器 文 持 存活 性 
探测 的 方法 包含 以 下 三 种 : ExecAction、TCPSocketAction 和 
HITITIPGetAction ° 


4.6.1 设置 exec 探 针 


exec 类 型 的 探 针 通过 在 目标 容器 中 执行 由 用 户 目 定义 的 命令 来 判 
定 容 器 的 健康 状态 ， 若 命令 状态 返回 值 为 0 则 表示 “成 功 ” 通 过 检测 ， 其 
值 均 为 “失败 ”状态 。“spec.containers.livenessProbe.exec” 字 上段 用 于 定义 
此 类 检测 ， 它 只 有 一 个 可 用 属性 “command”， 用 于 指定 要 执行 的 命 
令 。 下 面 是 定义 在 资源 清单 文件 liveness-exec.yaml 中 的 示例 : 


apiVersion: v1 
kind: Pod 
metadata: 
Jabels: 
test: liveness-exec 
name: liveness-exec 
spec: 
containers: 
- name: liveness-exec-demo 
image: busybox 


args: ["/bin/sh", "-c", " touch /tmp/healthy; Sleep 60; rm -rf /tmp/healthy; 
sleep 600"] 
livenessProbe: 
exec: 
command: ["test", "-e", "/tmp/healthy"] 


上 面 的 资源 清单 中 定义 了 一 个 Pod 对 象 ， 基 于 busybox 镜 像 局 动 一 
个 运行 “touch/tmp/healthy; sleep 60; rm-rf/tmp/healthy; sleep 600” 命 令 
的 容器 ， 此 命令 在 容 妖 启动 时 创建 /tmp/healthy 文 件 ， 并 于 60 秒 之 后 将 
其 删除 。 存 活性 探 针 运行 "test-e/tmp/healthy” 命 令 检 查 /tmp/healthy 文 件 
的 存在 性 ， 大 文件 存在 则 返回 状态 码 0， 表 示 成 功 通过 测试 。 


首先 ， 执 行 类 似 如 下 的 命令 ， 创 建 Pod 对 和 象 liveness-exec: 


~]$ kubectl1 apply -f liveness-exec.yaml 
pod "liveness-exec" created 


在 60 秒 之 内 使 用 “kubect describe pods/liveness-exec” 查 看 其 详细 信 
晨 ， 其 存活 性 探测 不 会 出 现 错误 。 而 超过 60 秒 之 后 ， 再 次 运行 “kubectl 
describe pods/liveness-exec” 查 看 其 详细 信息 可 以 发 现 ， 存 活性 探测 出 
Ce 和 并 且 阳 更 长 一 段 时 间 之 后 再 查看 其 至 还 可 以 看 到 容器 重启 


Type Reason Age From Message 

Warning Unhealthy 45s (x3 over 1m) kubelet, node02.ilinux.io Liveness 
probe failed: 

Normal Pulling 14s (x2 over 2m) kubelet, nodeQ02.ilinux.io pulling 
image "busybox" 

Normal Killing 14S kubelet，node02.1I1Linux.Io Killing 


container with id docker://liveness-demo:Container failed liveness probe.. 
Container will be killed and recreated. 

Normal Pulled 10s (x2 over 2m) kubelet, node02.ilinux.io 
Successfully pulled image "busybox" 


另外， 输出 信息 ne 一 段 中 还 清晰 地 显示 了 容器 健康 状 
态 检 测 及 状态 变化 的 相关 信息 : 容器 当 育 前 外 于 "Running 状态， 信和 = 
次 是 为 “Terminated”， 原 闲 是 送出 码 为 137 的 错误 信 局 它 示 示 进 程 是 
被 外 部 信号 所 终止 的 。137 事 实 上 是 由 两 部 分 数字 之 和 生成 的 : 
128+signum， 其 中 Signum 征 所 狼 进 各 终 世 的 信 号 的 数字 标识 ，9 表 示 
SIGKILL， 这 意味 着 进程 是 被 强行 终止 的 : 


lJiveness-exec-demo: 


State: Running 
Last State: Terminated 
Reason: Error 
Exit Code: 137 
Ready: True 
Restart Count: 1 
Liveness: exec [test -e /tmp/healthy] delay=0s timeout=1s period=10s 


#Ssuccess=1 #failure=3 


待 容 屁 重启 完成 后 再 次 查看 ， 容 屁 已 经 处 于 正常 运行 状态 ， 直 到 
文件 再 次 被 天 除 存活 性 探测 失败 而 重启 。 从 下 面 的 命令 显示 可 以 看 
出 ，liveness-exec 在 4 分 钟 时 间 内 已 然 重 启 了 两 次 : 


~]$ kubectl1 get pods liveness-exec 
NAME READY STATUS RESTARTS AGE 
liveness-exec 1/1 Running 2 4m 


需要 特别 说 明 的 是 ，exec 指 定 的 命令 运行 于 容器 中 ， 会 消耗 容 属 
的 可 用 资源 配额 ， 力 外 ， 考 处 到 探测 操作 的 效率 本 映 等 因素 ， 探 测 操 
作 的 命令 应 该 尽 可 能 简单 和 轻 量 。 


4.6.2 ”设置 HTTP 探 针 


基于 HTTP 的 探测 (HTTPGetAction) 向 目标 容器 发 起 一 个 HTTP 
请 求 ， 根 据 其 响应 码 进 行 结果 判定 ， 响 应 码 形 如 2xx 或 3xx 时 表示 检测 
通过 。“spec.containers.livenessProbe.httpGet” 字 段 用 于 定义 此 类 检测 ， 
它 的 可 用 配置 字段 包括 如 下 几 个 。 


.host<string> : 请 求 的 主机 地 址 ， 默 认为 PodIP; 也 可 以 在 
httpHeaders 中 使 用 “Host: ”来 定义 。 


.port<string> : 请 求 的 端口 ， 必 选 字段 。 
:httpHeaders<[]Object>: 目 定 义 的 请 求 报 文 首部 。 
.path<string> : 请 求 的 HTTP 资 源 路 径 ， 即 URL path。 


.Scheme: 建立 连接 使 用 的 协议 ， 仅 可 为 HTTP 或 HITPS， 默 认为 
HTTP 。 


下 面 是 一 个 定义 在 资源 清单 文件 liveness-http.yaml 中 的 示例 ， 它 通 
过 lifecycle 中 的 postStart hook 创 建 了 一 个 专用 于 httpGet 测 试 的 页 面 文件 
healthz: 


apiVersion: v1 
kind: Pod 
metadata: 

labels: 
test: liveness 

name: liveness-http 

spec: 

containers: 

- name: liveness-http-demo 
image: nginx:1.12-alpine 
ports: 

- name: http 
containerPort: 80 
lifecycle: 
postStart : 
exec: 
command: ["/bin/sh", "-c", " echo Healthy > /usr/share/nginx/html/ 
healthz"] 
livenessProbe: 
httpGet : 
path: /healthz 


port: http 
Scheme: HTTP 


上 面 清单 文件 中 定义 的 httpGet 测 试 中 ， 请 求 的 资源 路 径 
为 “healthz”， 地 址 默认 为 Pod IP， 端 口 使 用 了 容器 中 定义 的 端口 名 称 
J 站 明 要 雄 露 的 端口 的 用 途 之 一 。 首 先 创建 此 
Pod 六 


~]$ kubect1 apply -f liveness-http.yaml 
pod "liveness-http" created 


而 后 查看 其 健康 状态 检测 相关 的 信息 ， 健 康 状态 检测 正常 时 ， 容 
妖 也 将 正当 运行 : 


~]$ kubectl1 describe pods liveness-http 
Containers: 
liveness-http-demo: 


Port: 80/TCP 
State: Running 
Started: Thu, 21 Aug 2018 12:55:41 +0800 
Ready : True 
Restart Count: 0 
Liveness : http-get http://:http/healthz delay=0s timeout=1s period=10s 


#Ssuccess=1 #failure=3 


接 下 来 借助 于 “kubectl exec” 命 令 删 除 经 由 postStart hook 创 建 的 测 
试 页 面 healthz: 


$ kubect1 exec liveness-http rm /usr/share/nginx/html/healthz 


而 后 再 次 使 用 “kubectl describe pods liveness-http” 查 看 其 详细 的 状 
念 信息， 事件 输出 中 的 信息 可 以 表明 探测 测试 失败 ， 容 句 锐 共 挥 后 进 
行 了 重新 创建 : 


Events: 
Warning Unhealthy 28s (x3 over 48s) kubelet, node02.ilinux.io 
Liveness 
probe failed: HTTP probe failed with statuscode: 404 


Normal Killing 28s kubelet, nodeQ02.ilinux.io Killing 
container with id docker://liveness-demo:Container failed liveness probe.. 
Container will be killed and recreated. 


一 般 来 说 ，HTTP 类 型 的 探测 操作 应 该 针对 专用 的 URL 路 人 径 进 行 ， 
例如 ， 前 面 示例 中 特别 为 其 准备 的 “healthz”。 另 外 ， 此 URL 路 径 对 应 
的 Web 资 源 应 该 以 轻 量 化 的 方式 在 内 部 对 应 用 程序 的 各 关键 组 件 进行 
全 面 检测 以 确保 它们 可 正常 向 客 户 端 提 供 完 整 的 服务 。 


需要 注意 的 是 ， 这 种 检测 方式 仅 对 分 层 架 构 中 的 当前 一 层 有 效 ， 
例如 ， 它 能 检测 应 用 程序 工作 正常 与 否 的 状态 ,但 重 局 操作 却 无 法 解 
决 其 后 端 服务 (如 数据 库 或 缓存 服务 ) 导致 的 故障 。 此 时 ， 容 器 可 能 
会 被 一 次 次 的 重 局 ， 直 到 后 端 服务 恢复 正 党 为止。 其 他 两 种 检测 方式 
也 存在 类 似 的 问题 。 


4.6.3 ”设置 TCP 探 针 


基于 TCP 的 存活 性 探测 (TCPSocketAction) 用 于 回 容 器 的 特定 端 
口 发 起 TCP 请 求 并 尝试 建立 连接 进行 结果 判定 ， 连 接 建 立成 功 即 为 通 
过 检测 。 相 比较 来 说 ， 它 比 基 于 HTTP 的 探测 要 更 高 效 、 更 节约 资源 ， 
但 精准 度 略 低 ， 毕 况 连 接 建 立成 功 未 必 意 味 着 页 面 资 源 可 
用 。“spec.containers. we tcpSocket” 字 段 用 于 定义 此 类 检测 ， 
它 主要 包含 以 下 两 个 可 用 的 属性 。 


1) host<string>: 请 求 连接 的 目标 卫 地 址 ， 默 认为 Pod IP。 
2) port<string>: 请 求 连 接 的 目标 端口 ， 必 选 字段 。 


下 面 是 一 个 定义 在 资源 清单 文件 liveness-tcp.yaml 中 的 示例 ， 它 问 
J 了 PP 的 80mcp 端 口 发 起 连接 请 求 ， 并 根据 连接 建立 的 状态 判定 测试 结 


apiVersion: v1 
kind: Pod 
metadata: 

labels: 
test: liveness 

name: liveness-tcp 

spec: 

containers: 

- name: liveness-tcp-demo 
image: nginx:1.12-alpine 
ports: 

- name: http 
containerPort: 80 
livenessProbe: 
tcpSocket: 
port: http 


这 里 不 再 给 出 其 具体 的 创建 与 测试 过 程 ， 有 兴趣 的 读者 可 自行 进 
行 测试 。 


4.6.4 存活 性 探测 行为 属性 


使 用 kubectl describe 命 令 查 看 配置 了 存活 性 探测 的 Pod 对 象 的 详细 
信息 时 ， 其 相关 容器 中 会 输出 类 似 如 下 一 行 的 内 容 : 


Liveness: exec [test -e /tmp/healthy] delay=0s timeout=1s period=10s 
#success=1 #failure=3 


它 给 出 了 探测 方式 及 其 额外 的 配置 属性 delay 、timeout 、period、 
success 和 failure 及 其 各 目的 相关 属性 值 。 用 户 没 有 明确 定义 这 些 属 性 
字段 时 ， 它 们 会 使 用 各 自 的 默认 值 ， 例 如 上 面 显示 出 的 设 定 。 这 些 属 
性 信息 可 通过 “spec.containers.livenessProbe” 的 如 下 属性 字段 来 给 出 。 


initialDelaySeconds<integer> : 存活 性 探测 延迟 时 长 ， 即 容 句 启动 
多 久之 后 再 开始 第 一 次 探测 操作 ， 显 示 为 delay 属 性 ; 默认 为 0 秒 ， 即 
容器 启动 后 立刻 便 开始 进行 探测 。 


-timeoutSeconds<integer> : 存活 性 探测 的 超时 时 长 ， 显 示 为 
timeout 属 性 ， 默 认为 1s， 最 小 值 也 为 1s。 


:periodSeconds<integer> : 存活 性 探测 的 频 度 ， 显 示 为 period 属 
性 ， 默 认为 10s， 最 小 值 为 1s; 过 高 的 频率 会 对 Pod 对 和 象 市 来 较 大 的 额 
外 开销 ， 而 过 低 的 频率 又 会 使 得 对 错误 的 反应 不 及 时 。 


'SuccessThreshold<integer> : 处 于 失败 状态 时 ， 探 测 操作 至 少 连续 
多 少 次 的 成 功 才 被 认为 是 通过 检测 ， 显 示 为 #success 属 性 ， 默 认 值 为 
1， 最 小 值 也 为 1。 


failureThreshold: 处 于 成 功 状态 时 ， 探 测 操作 至 少 连续 多 少 次 的 
失败 才 被 视 为 是 检测 不 通过 ， 显 示 为 #failure 属 性 ， 默 认 值 为 3， 最 小 
值 为 1。 


例如 ， 这 里 可 将 4.6.1 节 中 清单 文件 中 定义 的 探测 示例 重新 定义 为 
如 下 所 示 的 内 容 : 


spec: 
containers: 
livenessProbe: 

exec: 
command: ["test", "-e", "/tmp/healthy"] 

initialDelaySeconds 5s 
timeoutSeconds 2s 
periodSeconds 5s 


根据 修改 的 清单 再 次 创建 Pod 对 象 并 进行 效 末 测试 ， 可 以 从 输出 
的 详细 信息 中 看 出 Liveness 已 经 更 新 到 目 定义 的 属性 ， 其 内 容 如 下 所 
示 。 具 体 过 程 这 里 不 再 给 出 ， 请 感 兴趣 的 读者 上 自行 测试 。 


Liveness: exec [test -e /tmp/healthy] delay=5s timeout=2s period=5s 
#success=1 #failure=3 


4.7 ”Pod 束 绪 性 探测 
pod 对 象 启动 后 ， 容 器 应 用 通常 需要 一 段 时 间 才能 完成 其 初始 化 


程 ， 帮 在 此 阶段 完成 之 前 即 接 入 客户 端的 请 求 ， 努 必 会 因为 等 竺 太 信 
而 影响 用 户 体 验 。 因 此 ， 应 该 避免 于 Pod 对 象 局 动 后 立即 让 其 处 理 客 
尸 问 请求 ， 而 是 等 得 容器 初始 化 工作 执行 完成 并 转 为 “就 绪 ” 状 态 ， 尤 
其 是 存在 其 他 提供 相同 服务 的 Pod 对 象 的 场景 更 是 如 此 。 


与 存活 性 探测 机 制 类 似 ， 束 绪 性 探测 征用 来 判 晰 容 需 殉 绪 与 否 的 
周期 性 (默认 周期 为 10 秒 钟 ， 操 作 ， 它 用 于 探测 容器 古 否 已 经 初始 化 
完成 并 可 服务 于 客户 端 请 求 ， 探 测 操作 返回 “success” 状 态 时 ， 即 为 传 
递 容器 已 经 “ 束 绪 ”的 信号 。 


与 存活 性 探测 机 制 相同 ， 就 绪 性 探测 也 支持 Exec、HTTP GET 和 
TCP Socket 三 种 探测 方式 ， 且 各 目的 定义 机 制 也 都 相同 。 但 与 存活 性 
探测 触发 的 操作 不 同 的 是 ， 探 测 失 败 时 ， 束 绪 性 探测 不 会 杀 死 或 重启 
容器 以 保证 其 健康 性 ， 而 是 通知 其 尚未 就 绕 ， 并 触发 依赖 于 其 就 绪 状 
态 的 操作 〈 例 如 ， 从 Service 对 象 中 移 除 此 Pod 对 象 ) 以 确保 不 会 有 客 
户 端 请求 接 入 此 Pod 对 象 。 不 过 ， 即 便 是 在 运行 过 程 中 ，Pod 束 线性 探 
测 依然 有 其 价值 所 在 ， 例 如 Pod A 依赖 到 的 Pod B 因 网 络 故障 等 原因 而 
不 可 用 时 ，Pod A 上 的 服务 应 该 转 为 未 吏 绪 状态 ， 以 免 无 法 回 客 户 端 提 
供 完 整 的 响应 。 


将 容 怖 定义 中 的 livenessProbe 字 段 名 替换 为 readinessProbe 即 可 定 
义 出 区 线性 探测 的 配置 ， 一 个 简单 的 示例 如 下 面 的 配置 清单 
(readiness-exec.yaml) 所 示 ， 它 会 在 Pod 对 象 创建 完成 5 秒 钟 后 使 用 
test-e/tmp/ready 命 令 来 探测 容器 的 就 线性 ， 命 令 执行 成 功 即 为 就 绪 ， 探 
测 周 期 为 5 秒 钟 : 


apiVersion: v1 
kind: Pod 
metadata: 
Jabels: 
test: readiness-exec 
name: readiness-exec 
spec: 
containers: 
- name: readiness-demo 


Image: busybox 
"while true; do rm -f /tmp/ready; Sleep 30; touch 


args: ["/bin/sh", "-c", 
/tmp/ready; Sleep 300; done"] 
readinessProbe: 
exec: 
command: ["test", "-e", "/tmp/ready"] 


initialDelaySeconds: 5 
periodSeconds: 5 


a ， 使 用 “kubectl create”" 命 令 将 资源 配置 清单 定义 的 资源 创建 到 


~]$ kubectl1 create -f readiness-exec.yaml 
pod/readiness-exec created 


接着 ， 运 行 "kubectl get-w” 命 令 监 视 其 资源 变动 信息 ， 由 如 下 命令 
结果 可 知 ， 尽 管 Pod 对 象 处 于 “Running” 状 态 ， 但 直到 就 结 探测 命令 执 
行 成 功 后 ，Pod 资 源 才 转 为 " 咕 绪 ”: 


~]$ kubect1 get pods -1 test=readiness-exec -Ww 


NAME READY STATUS RESTARTS AGE 
readiness-exec 0/1 Running 0 15S 
readiness-exec 1/1 Running 0 41S 


另外 ， 还 可 从 Pod 对 和 象 的 详细 信息 中 得 到 类 似 如 下 的 表示 其 已 经 
处 于 吏 绪 状态 的 信息 户 断 : 


Ready : True 
Restart Count: 0 
Readiness: exec [test -e /tmp/ready] delay=5s timeout=1s period=5s 
#success=1 

#failure=3 


这 里 需要 特别 提醒 读者 的 是 ， 示 定义 束 绪 性 探测 的 Pod 对 和 象 在 Pod 
进入 “Running” 状 态 后 将 立即 束 绪 ， 在 容 紫 需要 时 间 进 行 初始 化 的 场景 
中 ， 在 应 用 真正 束 绪 之 前 必然 无 法 正常 啊 应 客户 端 请 求 ， 因 此 ， 生 产 
实践 中 ， 必 须 为 关键 性 Pod 资 源 中 的 容器 定义 束 绪 性 探测 机 制 。 其 探 
测 机 制 的 定义 请 参考 4.6 节 中 的 定义 。 


4.8 ”资源 需求 及 依 源 限 制 


在 Kubernetes 上， 可 由 容器 或 Pod 请 求 或 消费 的 “计算 资源 ”是 指 
CPU 和 内 存 (RAM) ， 这 也 是 目前 仅 有 的 受 文 持 的 两 种 类 型 。 相 比较 
来 说 ，CPU 必 于 可 压缩 (compressible) 型 资源 ， 即 资源 额度 可 按 需 收 
缩 ， 而 内 存 〈 当 前) 则 是 不 可 压缩 型 资源 ， 对 其 执行 收缩 操作 可 能 会 
导致 某 种 程度 的 问题 。 


目前 来 说 ， 痪 源 隔离 尚且 属于 容 亏 级 别 ，CPU 和 内 存 资 源 的 配置 
需要 在 Pod 中 的 容器 上 进行 ， 每 种 资源 均 可 由 “requests” 属 性 定义 其 请 求 
的 确保 可 用 值 ， 即 容器 运行 可 能 用 不 到 这 些 额 度 的 资源 ， 但 用 到 时 必 
须要 确保 有 如 此 多 的 资源 可 用 ， 而 "limits" 属 性 则 用 于 限制 资源 可 用 的 
最 大 值 ， 即 便 限 制 ， 如 图 4-12 所 示 。 不过， 为 了 表述 方便 ， 人 人们 通常 仍 
然 把 痪 源 配 置 称 作 Pod 资 源 的 请 求 和 限制 ， 只 不 过 它 是 指 Pod 内 所 有 容 
故 上 某 种 类 型 多 源 的 请 求 和 限制 的 总 和 。 


Maximum CPU resources for container 


cpu.requests=200m cpu.limits=500m 


< 基 二 > 


Guaranteed TeESOUICEeS Throttled TeESOUICES 
图 4-12 ”容器 资源 需求 及 资源 限制 示意 图 


在 Kubernetes 系 统 上 ，1 个 单位 的 CPU 相 当 于 虚拟 机 上 的 1 颗 虚 拟 
CPU (vCPU) 或 物理 机 上 的 一 个 超 线程 (Hyperthread， 或 称 为 一 个 逻 
辑 CPU) ， 它 支持 分 数 计量 方式 ， 一 个 核心 \lcore) 相当 于 1000 个 微 
核心 (millicores) ， 因 此 500m 相 当 于 是 0.5 个 核心 ， 即 二 分 之 一 个 核 
心 。 内 存 的 计量 方式 与 日 常 使 用 方式 相同 ， 默 认 单 位 是 字 节 ， 也 可 以 
使 用 E、P、T、G、M 和 K 作 为 单位 后 级 ， 或 Ei、Pi、Ti、Gi、Mi 和 Ki 形 
式 的 单位 后 级 。 


下 面 的 示例 中 ， 目 主 式 Pod 要 求 为 stress 容 器 确 你 128Mi 的 内 存 及 五 
分 之 一 个 CPU 核心 (200m) 资源 可 用 ， 它 运行 stress-ng 镜 像 启动 一 个 
进程 (-m 1) 进行 内 存 性 能 压力 测试 ， 满 载 测试 时 它 也 会 尽 可 能 多 地 
占用 CPU 资 源 ， 男 外 再 局 动 一 个 专用 的 CPU 压 力 测试 进程 (-c1) 。 
stress-ng 是 一 个 多 功能 系统 压力 测试 具 ，master/worker 模 型 ，Master 为 
主 进程 ， 负 责 生 成 和 控制 子 进程 ，worker 是 负责 执行 各 类 特定 测试 的 
子 进 程 ， 例 如 测试 CPU 的 子 进程 ， 以 及 测试 RAM 的 子 进程 等 : 


apiVersion: v1 
kind: Pod 
metadata: 
name: stress-pod 
spec: 
containers: 
- name: stress 
image: ikubernetes/ stress-ng 
command: ["/usr/bin/stress-ng", "-m 1", "-c 1", "-metrics-brief"] 
resources: 
requests: 
memory: "128Mi" 
cpu: "200m" 


上 面 的 配置 清单 中 ， 其 请 求 使 用 的 CPU 资 源 大 小 为 200m， 这 意味 
着 一 个 CPU 核 心 足 以 确保 其 以 期 望 的 最 快 方式 运行 。 男 外 ， 配 置 清单 
中 期 望 使 用 的 内 存 大 小 为 128Mi， 不 过 其 运行 时 未 必 真 的 会 用 到 这 么 
多 。 考 虑 到 内 存 为 非 压 缩 型 资源 ， 其 超出 指定 的 大 小 在 运行 时 存在 被 
， 于 是 请 求 值 也 应 该 束 是 其 理想 中 使 用 的 内 
子 空间 


接 下 来 创建 并 运行 此 Pod 对 其 资源 限制 效果 进行 检查 。 需 要 特别 
说 明 的 是 ， 笔 者 当前 使 用 的 系统 环境 中 ， 每 个 节点 的 可 用 CPU 核心 数 
均 为 98， 物理 内 存 空间 为 16GB: 


~]$ kubectl create -f pod-resources-test.yaml 


而 后 在 Pod 资 源 的 容 莫 内 运行 top 命 令 观 察 其 CPU 及 内 存 资源 的 占 
用 状态 ， 如 下 所 示 ， 其 中 {stress-ng-vm} 是 执行 内 存 压 测 的 子 进 程 ， 它 


| 256m 的 内 存 空 间 ，{stress-ng-cpu} 是 执行 CPU 压 测 的 专用 子 进 


~]$ kubectl1 exec stress-pod -- top 

Mem: 2884676K used, 13531796K free, 27700K shrd, 2108K buff, 1701456K cached 
CPU: 25% usr 0% sys 0% nic 74% idle 0% io 0% rd QO% Sird 

Load average: 0.57 0.60 0.71 3/435 15 

PID PPID USER STAT VSZ %VSZ CPU %CPU COMMAND 


9 8 root R 262m 2% 6 13% {stress-ng-vm} /usr/bin/stress-ng 
7 1 root R 6888 0% 3 13% {stress-ng-cpu} /usr/bin/stress-ng 
1 © root S 6244 0% 1 0% /usr/bin/stress-ng -c 1 -m 1 --met 


top 命 令 的 输出 结果 显示 ， 每 个 测试 进程 的 CPU 占用 率 为 13% ( 实 
际 为 12.5%) ，f{stress-ng-vm} 的 内 存 占用 量 为 262m (VSZ) ， 此 两 项 
资源 占用 量 都 远 超 其 请 求 的 用 量 ， 原 因 是 stress-ng 会 在 可 用 的 范围 内 
尽量 多 地 占用 相关 的 资源 。 两 个 测试 线程 分 布 于 两 个 CPU 核心 以 满载 
的 方式 运行 ， 系 统 共有 8 个 核心 ， 因 此 其 使 用 率 为 259% (2/8) 。 另 
外 ， 克 点 上 的 内 存 资源 充裕 ， 昌 然 容器 的 内 存 用 量 远 超 128M， 但 它 依 
然 可 运行 。 一 旦 资源 紧张 时 ， 市 点 仪 保证 容器 有 五 分 之 一 个 CPU 核 心 
可 用 ， 对 于 有 着 8 个 核心 的 节点 来 说 ， 它 的 占用 率 为 2.5%， 于 是 每 个 
进程 为 1.25%， 多 占用 的 资源 会 被 压缩 。 内存 为 非 可 压缩 型 资源 ， 所 
以 此 Pod 在 内 存 资源 紧张 时 可 能 会 央 OOM 被 杀 死 (killed) 。 


对 于 压缩 型 的 资源 CPU 来 说 ， 未 定义 其 请 求 用 量 以 确保 其 最 小 的 
可 用 资源 时 ， 它 可 能 会 被 其 他 的 Pod 资 源 压缩 至 极 低 的 水 平 ， 甚 至 会 
达到 Pod 不 能 够 被 调度 运行 的 境地 。 而 对 于 非 压缩 型 资源 来 说 ， 内 存 
资源 在 任何 原因 导致 的 紧缺 情形 下 都 有 可 能 导致 相关 的 进程 被 杀 死 。 
因此 ， 在 Kubernetes 系 统 上 运行 关键 型 业务 相关 的 Pod 时 必须 使 用 
requests 属 性 为 容器 定义 资源 的 确保 可 用 量 。 


集群 中 的 每 个 节点 都 拥有 定量 的 CPU 和 内 存 资源 ， 调 度 Pod 时 ， 仅 
那些 被 请 求 资 源 的 余 量 可 容纳 当前 被 调度 的 Pod 的 请 求 量 的 和 点 才 可 
作为 目标 节点 。 也 就 是 说 ，Kubernetes 的 调度 器 会 根据 容器 的 requests 
属性 中 定义 的 资源 需求 量 来 判定 仅 哪 些 节 点 可 接收 运行 相关 的 Pod 资 
源 ， 而 对 于 一 个 节点 的 资源 来 说 ， 每 运行 一 个 Pod 对 象 ， 其 requests 中 
定义 的 请 求 量 都 要 被 预 留 ， 直 到 被 所 有 Pod 对 象 瓜分 完毕 为 止 。 


4.8.2 ”资源 限制 


容 絮 的 资源 需求 仅 能 达到 为 其 保证 可 用 的 最 少 资源 量 的 目的 ， 它 
并 不 会 限制 容器 的 可 用 资源 上 限 ， 因 此 对 因应 用 程序 自身 存在 Bug 等 
多 种 原因 而 导致 的 系统 资源 被 长 时 间 占 用 的 情况 则 无 计 可 施 ， 这 残 需 
要 通过 limits 属 性 为 容 右 定义 资源 的 最 大 可 用 量 。 资 源 分 配 时 ， 可 压缩 
型 资源 CPU 的 控制 阀 可 目 由 调节 ， 容 右 进 程 无 法 获得 超出 其 CPU 配 额 
的 可 用 时 间 。 不 过 ， 如 果 进 程 申请 分 配 超 出 其 limits 属 性 定义 的 硬 限制 
的 内 存 资源 时 ， 它 将 被 OOM killer 杀 死 ， 不 过 ， 随 后 可 能 会 被 其 控制 
进程 所 重启 ， 例 如 ， 容 器 进程 的 Pod 对 象 会 被 杀 死 并 重启 (重启 策略 
为 Always 或 OnFailure 时 ) ， 或 者 是 容 右 进程 的 于 进程 伞 其 父 进程 所 重 


局 运 


下 面 的 配置 清单 文件 (memleak-pod.yaml) 中 定义 了 如 何 使 用 
saadali/simmemleak 镜 像 运行 一 个 Pod 对 象 ， 它 模拟 内 存 泄 漏 操作 不 叫 
地 申请 使 用 内 存 资源 ， 直 到 超出 limits 属 性 中 memory 字 段 设 定 的 值 而 
导致 *OOMKillled” 为 止 : 


apiVersion: v1 
kind: Pod 
metadata: 

name: memleak-pod 

labels: 
app: memleak 

spec: 

containers: 

- name: simmemleak 
image: saadali/simmemleak 
resources: 

requests: 
memory: "64Mi" 
cpu: i 
limits: 
memory: "64Mi" 
cpu: i 


下 面 测试 其 运行 效果 ， 首 先 将 配置 清单 中 定义 的 资源 复 用 下 面 的 
命令 创建 于 集群 中 : 


~]$ kubect1 apply -f memleak-pod.yaml 
pod/memleak created 


Pod 资 源 的 默认 重启 人蛇 略为 Always， 于 是 在 memleak 因 内 存 资 源 达 
到 便 限 制 而 被 终止 后 会 立即 重启 ， 因 此 用 户 很 难 观察 到 其 因 OOM 而 被 
杀 死 的 相关 信息 。 不 过 ， 多 次 重复 地 因为 内 存 资源 耗 尽 而 重 局 会 触发 
Kubernetes 系 统 的 重启 延迟 机 制 ， 即 每 次 重启 的 时 间 间 陋 会 不 断 地 拉 
长 。 于 是 ， 用 户 看 到 的 Pod 资 源 的 相关 状态 通常 
为 “CrashLoopBackOff”: 


~]$ kubectl1 get pods -1 app=memleak 
NAME READY STATUS RESTARTS AGE 
memleak-pod 0/1 CrashLoopBackOoff 1 24S 


Pod 资 源 首 次 的 重启 将 在 crash 后 立即 完成 ， 帮 随后 再 次 crashn， 那 
么 其 重 局 操作 会 延迟 10 秒 进行 ， 随 后 的 延迟 时 长 会 逐渐 增加 ， 依 次 为 
20 秒 、40 秒 、80 秒 、160 秒 和 300 秒 ， 随 后 的 延迟 将 固定 在 5 分 钟 的 时 长 
之 上 而 不 再 增加 ， 直 到 其 不 再 crash 或 者 delete 为 止 。describe 命 令 可 以 
显示 其 状态 相关 的 详细 信息 ， 其 部 分 内 容 如 下 所 示 : 


~]$ kubect1 describe pods memleak-pod 


Name : memleak-pod 
Last State: Terminated 
Reason: OOMKilled 
Exit Code: 137 
Started: Wed, 02 May 2018 12:42:50 +0800 
Finished: Wed, 02 May 2018 12:42:50 +0800 
Ready: False 


Restart Count: 3 


如 上 述 命 令 结 果 所 显示 的 ，OOMKilled 表 示 容 器 因 内 存 耗 尽 而 被 
终止 ， 因此， 为 limits 属 性 中 的 memory 设 置 一 个 合理 值 至 关 重 要 。 与 
requests 不 同 的 是 ，limits 并 不 会 影响 Pod 的 调度 结果 ， 也 就 是 说 ， 一 个 
节点 上 的 所 有 Pod 对 象 的 limits 数 量 之 和 可 以 大 于 节点 所 拥有 的 资源 
量 ， 即 支持 资源 的 过 载 使 用 (overcommitted) 。 不 过 ， 这 么 一 来 一 旦 
资源 耗 尽 ， 尤 其 是 内 存 资源 耗 尽 ， 则 必然 会 有 容器 因 OOMKilled 而 终 
上 上 上 。 


另外 需要 说 明 的 是 ，Kubernetes 仅 会 确保 Pod 能 够 获得 它们 请 求 
(requests) 的 CPU 时 间 额 度 ， 它 们 能 否 获 得 额外 (throttled) 的 CPU 


时 间 ， 则 取决 于 其 他 正在 运行 的 作业 对 CPU 资源 的 占用 情况 。 例 如 ， 
对 于 总 数 为 1000m 的 CPU 资源 来 说 ， 容 器 A 请 求 使 用 200m， 容 器 B 请 求 
使 用 500m， 在 不 超出 它们 各 自 的 最 大 限额 的 前 提 下 ， 余 下 的 300m 在 
双方 都 需要 时 会 以 2: 5 (200m: 500m) 的 方式 进行 配置 。 


4.8.3 ”上 容 需 的 可 见 资源 


细心 的 读者 可 能 已 经 发 现 了 这 一 点 : 于 容 妖 中 运行 top 等 命令 观察 
资源 可 用 量 信息 时 ， 即 便 定 义 了 requests 和 1limits 属 性 ， 虽 然 其 可 用 资 
源 受 限 于 此 两 个 属性 中 的 定义 ， 但 容 喜 中 可 见 的 资源 量 依然 是 和 点 级 
别 的 可 用 总 量 。 例 如 ， 为 前 面 定 义 的 stress-pod 添 加 如 下 limits 属 性 定 
义 : 


limits: 
memory: "512Mi" 
cpu: "400m" 


重新 创建 stress-pod 对 象 ， 并 于 其 容 旭 内 分 别 列 出 容器 可 见 的 内 存 
和 CPU 资源 总 量 ， 命 令 及 结 采 如 下 所 示 : 


~]$ kubect1 exec Stress-pod -- cat /proc/meminfo | grep ^MemTotal 
MemTotal: 16416472 KkB 
$ kubectl1 exec stress-pod -- cat /proc/cpuinfo | grep -c ^processor 
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命令 结果 中 显示 其 可 用 内 存 资源 总 量 为 16416472KB (16GB) ， 
CPU 核心 数 为 8 个 ， 这 是 和 点 级 的 资源 数量 ， 而 非 由 容器 的 limits 所 定 
义 的 512Mi 和 400m。 其 实 ， 这 种 结果 不 仅仅 使 得 其 查看 命令 的 显示 结 
果 看 起 来 有 些 奇怪 ， 而 且 对 有 些 容器 应 用 的 配置 也 会 带 来 不 小 的 负面 


影响 。 


较为 典型 的 是 在 Pod 中 运行 Java 应 用 程序 时 ， 者 未 使 用 "<-Xmx" 选 
项 指定 JVM 的 堆 内 存 可 用 总 量 ， 它 默认 会 设置 为 主机 内 存 总 量 的 一 个 
空间 比例 (如 30%) ， 这 会 导致 容器 中 的 应 用 程序 申请 内 存 资源 时 将 
会 达到 上 限 而 转 为 OOMKilled。 男 外 ， 即 便 使 用 了 “-Xmx” 选 项 设置 其 
堆 内 存 上 限 ， 但 它 对 于 非 堆 内 存 的 可 用 空间 不 会 产生 任何 限制 作用 ， 
结果 是 仍然 存在 达到 容 絮 内 存 资 源 上 限 的 可 能 性 。 


另 一 个 颇具 代表 性 的 场景 是 于 Pod 中 运行 的 nginx 应 用 ， 在 配置 参 
数 worker_processes 的 值 为 "auto" 时 ， 主 进程 会 创建 与 Pod 中 能 够 访问 到 
的 CPU 核心 数 相 同 数量 的 worker 进 程 。 者 Pod 的 实际 可 用 CPU 核心 远 低 


于 主机 级 别 的 数量 时 ， 那么 这 种 设 鞋 在 较 大 且 开 发 访问 ] 人 负 集 下 会 导致 
严重 的 资源 竞争 ， 并 将 带 来 更 多 的 内 存 资 源 消耗 。 一 个 较为 妥当 的 解 
决 方案 是 使 用 Downward Si 量 暴露 给 人 人 
点 将 在 后 面 的 章 广 中 予以 介 


4.8.4 Pod 的 服务 质量 类 别 


前 面 曾 提 人 到 过 ，Kubernetes 人 允许 广 点 资源 对 limits 的 过 载 使 用 ， 这 
意味 着 广 点 无 法 同时 满足 其 上 的 所 有 Pod 对 象 以 资源 满载 的 方式 运 
行 。 于 是 ， 在 内 存 资源 紧缺 时 ， 应 该 以 何 种 次 序 先 后 终止 哪些 Pod 对 
象 ? Kubermetes 无 法 目 行 对 此 做 出 决 案 ， 它 需要 借助 于 Pod 对 象 的 优先 
级 完成 判定 。 根 据 Pod 对 象 的 requests 和 1limits 属 性 ，Kubernetes 将 Pod 对 
象 归 类 到 BestEfftort、Burstable 和 Guaranteed 三 个 服务 质量 (Quality of 
Service，QoS) 类 别 下 ， 具 体 说 明 如 下 。 


Guaranteed: 每 个 容器 都 为 CPU 资源 设置 了 具有 相同 值 的 requests 
和 limits 属 性 ， 以 及 每 个 容 絮 都 为 内 存 资 源 设 置 了 具有 相同 值 的 
requests 和 limits 属 性 的 Pod 资 源 会 目 动 归属 于 此 类 别 ， 这 类 Pod 资 源 具 
有 最 高 优先 级 。 


.Burstable: 至 少 有 一 个 容 需 设置 了 CPU 或 内 存 资源 的 requests 属 
性 ， 但 不 满足 Guaranteed 类 别 要 求 的 Pod 资 源 将 自动 归属 于 此 类 别 ， 它 
们 具有 中 等 优先 级 。 


.BestEffort: 未 为 任何 一 个 容器 设置 requests 或 limits 属 性 的 Pod 资 源 
将 自动 归属 于 此 类 别 ， 它 们 的 优先 级 为 最 低级 别 。 


内 存 资 源 鞭 缺 时 ，BestEffort 类 别 的 容器 将 首当其冲 地 被 终止 ， 
为 系统 不 为 其 提供 任何 级 别 的 资源 保证 ， 但 换 来 的 好 处 是 ， 它 们 能 够 
在 可 用 时 做 到 尽 可 能 多 地 占用 资源。 知已 然 不 存 任何 BestEffort 类 别 的 
容 絮 ， 则 接 下 来 是 有 着 中 等 优先 级 的 Burstable 类 别 的 Pod 被 终止 。 
Guaranteed 类 别 的 容器 拥有 最 高 优先 级 ， 它 们 不 会 被 杀 死 ， 除 非 其 内 
存 资 源 需 求 超 限 ， 或 者 OOM 时 没有 其 他 更 低 优先 级 的 Pod 资 源 存在 。 


每 个 运行 状态 容器 都 有 其 OOM 得 分 ， 得 分 越 高 越 会 被 优先 杀 死 。 
OOM 得 分 主要 根据 两 个 纬度 进行 计算 : 由 QoS 类 别 继承 而 来 的 默认 分 
值 和 容器 的 可 用 内 存 资源 比例 。 同 等 类 别 的 Pod 资 源 的 默认 分 值 相 
同 ， 下 面 的 代码 片段 取 上 自 pkg/kubelet/qos/policy.go 源 码 文 件 ， 它 们 定义 
的 是 各 种 类 别 的 Pod 资 源 的 OOM 调 节 (Adjust) 分 值 ， 即 默认 分 值 。 
其 中 ，Guaranteed 类 别 的 Pod 资 源 的 Adjust 分 值 为 -998， 而 BestEffort 类 


别 的 默认 分 值 为 1000，Burstable 类 别 的 Pod 资 源 的 Adjust 分 值 则 经 由 相 
应 的 算法 计算 得 出 : 


const ( 
PodInfraOOMAd] int = -998 
KubeletOOMScoreAd]j int = -999 
DockerOOMScoreAdj int = -999 
KubeProxyOOMScoreAdj int = -999 


guaranteedoOMScoreAdj int -998 
besteffortOOMScoreAdj int = 1000 


因此 ， 同 等 级 别 优先 级 的 Pod 资 源 在 OOM 有 时， 与 自身 的 requests 属 
性 相 比 ， 其 内 存 占用 比例 最 大 的 Pod 对 象 将 被 首先 杀 死 。 例 如 ， 图 4-13 
中 的 同属 于 Burstable 类 别 的 Pod A 将 先 于 Pod B 被 杀 死 ， 虽 然 其 内 存 用 
量 小 ， 但 与 自身 的 requests 值 相 比 ， 它 的 占用 比例 95% 要 大 于 Pod B 的 
80% ° 


需要 特别 说 明 的 是 ，OOM 和 是 内 存 耗 尽 时 的 处 理 机 制 ， 它 们 与 可 讨 
缩 型 货源 CPU 无 关 ， 因 此 CPU 资源 的 需求 无 法 得 到 保证 时 ，Pod 仅 仅 十 
暂时 获取 不 到 相应 的 资源 而 已 。 
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图 4-13 ”资源 需求 、 资 源 限 额 及 OOM 


4.9 ”本章 小 结 


本 章 介绍 了 Pod 资 源 的 基础 概念 、 分 布 式 系统 的 设计 模式 、Pod 的 
基础 管理 操作 、 如 何 定义 和 管理 容器 、 资 源 标签 和 标签 选择 胡 、 资 源 
注解 等 ， 详 细 讲 解 了 Pod 生 命 周 期 中 的 事件 、 容 右 的 存活 性 探测 各 
绪 性 探测 机 制 等 话题 。 


:Pod 束 是 联系 紧密 的 一 组 容器 ， 它 们 共享 Network、UTS 和 IPC 名 
称 空间 及 存储 卷 资 源 。 


分布 式 系统 设计 主要 有 Sidecar、Ambassador 和 Adapter 三 种 主要 模 

-Kubernetes 资 源 对 象 的 管理 操作 基本 上 是 由 增 、 删 、 改 和 查 等 操 
作 组 成 的 ， 并 且 文 持 陈 述 式 命令 、 陈 述 式 对 象 配置 和 声明 式 对 象 配置 
三 种 管理 方式 。 


:Pod 的 核心 目标 在 于 运行 容器 ， 容 右 的 定制 配置 常见 的 包括 其 露 
端口 及 传递 环境 变量 等 。 

.标签 是 附加 在 Kubernetes 系 统 上 的 键 值 类 型 的 元 数据 ， 而 标签 先 
择 器 是 基本 等 值 或 集合 关系 的 标 等 过 滤 机 制 ; 注解 类 似 于 标签， 但 不 
能 被 用 于 标 等 选择 器 。 


-Pod 的 生命 周期 中 可 能 存在 多 种 类 型 的 操作 ， 但 运行 主 容 右 古 其 
核心 任务 。 


:存活 性 探测 及 吏 绪 性 探测 是 辅助 判定 容 需 状态 的 重要 工具 。 
资源 需求 及 资源 限制 是 管理 Pod 对 象 系统 资源 分 配 的 有 效 方式 。 


第 5 章 ”Pod 控 制 器 


自主 式 Pod 对 和 象 由 调度 需 绑 定 至 目标 工作 和 点 后 即 由 相应 节点 上 
的 kubelet 负 责 监 控 其 容器 的 存活 性 ， 容 器 主 进 程 朋 尝 后 ，kubelet 能 够 
自动 重启 相应 的 容器 。 不 过 ，kubelet 对 非 主 进程 朋 溃 类 的 容器 错误 却 
无 从 感知 ， 这 依赖 于 用 户 为 Pod 资 源 对 象 自 定 义 的 存活 性 探测 
(liveness probe) 机 制 ， 以 便 kubelet 能 够 探知 到 此 类 故障 。 然 而 ， 在 
Pod 对 象 遭 到 意外 删除 ， 或 者 工作 和 点 目 身 发 生 故 障 时 ， 又 该 如 何 处 
理 呢 ? 


kubelet 是 Kubernetes 集 群 节 点 代理 程序 ， 它 在 每 个 工作 市 点 上 都 运 
行 着 一 个 实例 。 因 而 ， 集 群 中 的 某 工 作 市 点 发 生 故 障 时 ， 其 kubelet 也 
必 将 不 再 可 用 ， 于 是 ， 节 点 上 的 Pod 资 源 的 健康 状态 将 无 从 得 到 保 
证 ， 也 无 法 再 由 kubelet 重 启 。 此 种 场景 中 的 Pod 存 活性 一 般 要 由 工作 市 
点 之 外 的 Pod 控 制 絮 来 保证 。 事 实 上 ， 遭 到 意外 删除 的 Pod 资 源 的 恢复 
也 依赖 于 其 控制 器 。 


Pod 控 制 妖 由 master 的 kube-controller-manager 组 件 提 供 ， 常 见 的 此 
类 控制 器 有 ReplicationController、ReplicaSet、Deployment、 
DaemonSet、StatefulSet、Job 和 CronJob 等 ， 它 们 分 别 以 不 同 的 方式 管 
理 Pod 资 源 对 象 。 实 践 中 ， 对 Pod 对 象 的 管理 通常 都 是 由 某 种 控制 妖 的 
特定 对 象 来 实现 的 ， 包 括 其 创建 、 删 除 及 重新 调度 等 操作 。 本 章 将 逐 
一 讲解 常用 的 Pod 控 制 器 资源 。 


5.1 天 于 Pod 控 制 器 


我 们 可 以 把 API Server 类 比 成 一 个 存储 对 象 的 数据 库 系 统 ， 它 向 客 
户 问 提供 了 API， 并 人 负责 存储 由 用 户 创建 的 各 种 资源 对 象 ， 人 至 于 各 对 
象 的 当前 状态 如 何 才能 符合 用 户 期 望 的 状态 ， 则 需要 交 由 男 一 类 称 为 
控制 器 的 组 件 来 负责 完成 。Kubernetes 提 供 了 众多 的 控制 器 来 管理 各 
种 类 型 的 资源 ， 如 Node Lifecycle Controller、Namespace Controller 、 
Service Controller 和 Deployment Controller 等 ， 它 们 的 功用 几乎 可 以 做 
到 见 名 知 义 。 创 建 完 成 后 ， 每 一 个 控制 絮 对 象 都 可 以 通过 内 部 的 和 解 
循环 (reconciliation loop) ， 不 间断 地 监控 着 由 其 负责 的 所 有 资源 并 确 
保 其 处 于 或 不 断 地 通 近 用 户 定义 的 目标 状态 。 


尽管 能 够 由 kubelet 为 其 提供 目 剑 能 力 ， 但 在 节点 宕 机 时 ， 上 自主 式 
Pod 对 和 象 的 重建 式 目 愈 机 制 则 需要 由 Pod 控 制 絮 对象 负 贡 提供 ， 并 且 由 
它 来 负责 实现 生命 周期 中 的 各 类 目 动 管理 行为 ， 如 创建 及 删除 等 。 


5.1.1 Pod 控制 器 概述 


Master 的 各 组 件 中 ，API Server 仅 负责 将 资源 存储 于 etcd 中 ， 并 将 

其 变动 通知 给 各 相关 的 客户 端 程序 ， 如 kubelet、kube-scheduler、kube- 
proxy 和 kube-controller-manager 等 ，kube-scheduler 监 探 到 处 于 未 绑 定 状 
态 的 Pod 对 象 出 现时 遂 启 动 调度 器 为 其 挑选 适 配 的 工作 节点 ， 然 而 ， 
Kubernetes 的 核心 功能 之 一 还 在 于 要 确保 各 资源 对 象 的 当前 状态 

(status) 以 匹配 用 户 期 望 的 状态 (spec) ， 使 当前 状态 不 断 地 疝 期 望 
状态 “和 解 ” (reconciliation) 来 完成 容器 应 用 管理 ， 而 这 些 则 是 kube- 
controller-manager 的 任务 。kube-controller-manager 是 一 个 独立 的 单 体 守 
护 进程 ， 然 而 它 包 含 了 从 多 功能 不 同 的 控制 器 类 型 分 别 用 于 各 类 和 解 
任务 ， 如 图 5-1 所 示 。 


Node X 


Controller-Manager 


Node Controllers 
DaemonSet Controllers 


StatefulSet Controllers 


Deployment Controllers 


myapp-deploy 


kubelet 


图 5-1 ”kube-controller-manager 及 其 控制 器 


@ 提示 ”Kubernetes 可 用 的 控制 器 有 attachdetach 、 
bootstrapsigner 、 clusterrole-aggregation 、 cronjob 、 csrapproving 、 
csrcleaner 、 csrsigning ~ daemonset 、 deployment 、 disruption 、 endpoint 、 
garbagecollector 、 horizontalpodautoscaling 、 job 、 namespace 、 node 、 
persistentvolume-binder ~、 persistentvolume-expander ~ podgc 、 pvc- 
protection 、 replicaset 、 replication- controller ~、 resourcequota 、 route 、 
service 、 serviceaccount 、 serviceaccount-token 、statefulset 、 tokencleaner 


和 也 等 数 十 种 。 


创建 为 具体 的 控制 器 对 象 之 后 ， 每 个 控制 器 均 通 过 API Server 提 供 
的 接口 持续 监控 相关 资源 对 象 的 当前 状态 ， 并 在 因 故 障 、 
原因 导致 系统 状态 发 生变 化 时 ， 和 尝试 让 资源 的 当前 状态 同期 望 状态 
移 和 代 近 。 简 单 来 说 ， 每 个 控制 妖 对 象 运行 一 个 和 人 解 循 环 人 负责 po 
解 ， 并 将 日 标 资源 对 象 的 当前 状态 写 入 到 其 status 字 段 中 。 控 制 器 的 “ 利 
解 ” 循 环 如 图 5-2 所 示 。 


(人 


reconciliation 


图 5-2 ”控制 万 的 "和解 ? 循 环 


List-Watch 是 Kubernetes 实 现 的 核心 机 制 之 一 ， 资源 对 象 的 状态 
发 生变 动 时 ， 由 API Server 负 责 写 入 tcq 并 通过 水 平 航 必 J 
triggered) 机 制 主 动 通知 给 相关 的 客户 端 程序 以 确保 其 不 会 错过 任何 一 
个 事件 。 控 制 器 通过 API Server 的 watch 接 口 实 时 监控 目 标 资源 对 象 的 变 
动 并 执行 和 解 操作 ， 但 并 不 会 与 其 他 控制 器 进行 任何 交互 ， 甚 至 彼此 
之 间 根 本 就 意识 不 到 对 方 的 存在 。 


工作 负载 (workload) 一 类 的 控制 器 资源 类 型 包括 
ReplicationController、Replicaset、Deployment、DaemonsSet 、 
StatefulSet、Job 和 CronJob 等 ， 它 们 分 别 代 表 了 一 种 类 型 的 Pod 挥 制 如 次 
源 ， 各 类 型 的 功用 在 3.1.1 市 中 已 经 给 出 过 说 明 。 本 章 后 面 的 篇 幅 主 要 
介绍 各 控制 絮 的 特性 及 其 应 用 ， 不 过 StatefulSet 控 制作 依赖 于 存储 卷 资 
源 ， 因 此 它 将 单独 在 存储 卷 之 后 的 章节 中 给 予 介绍 。 


5.1.2 ”控制 妖 与 Pod 对 象 


Pod 挥 制 右 资源 通过 持续 性 地 监控 集群 中 运行 着 的 Pod 资 源 对 象 来 
确 祭 受 其 管控 的 资源 闫 格 符合 用 户 期 户 的 状态 ， 例 如 资源 副本 的 数量 
要 精确 符合 期 望 等 。 通 常 ， 一 个 Pod 控 制 右 资源 至 少 应 该 包含 三 个 基本 
的 组 成 部 分 。 


-标签 选择 器 : 匹配 并 关联 Pod 资 源 对 象 ， 并 据 此 完成 受 其 管控 的 
Pod 资 源 计 数 。 

期望 的 副本 数 : 期 望 在 集群 中 精确 运行 着 的 Pod 资 源 的 对 象 数 量 。 

.Pod 模板 : 用 于 新 建 Pod 资 源 对 象 的 Pod 模 板 资源 。 


© 注意 “DaemonSet 用 于 确保 集群 中 的 每 个 工作 节点 或 符合 条 
件 的 每 个 节点 上 都 运行 着 一 个 Pod 副 本 ， 而 不 是 某 个 精确 的 数量 值 ， 
此 不 具有 上 面 组 成 部 分 中 的 第 二 项 。 


例如 ， 一 个 如 图 5-3 所 示 的 Deployment 控 制 器 资源 使 用 的 标签 选择 
独 为 “role=be-eshop”， 它 期 望 相关 的 Pod 资 源 副 本 数量 精确 为 3 个 ， 少 于 
此 数量 的 缺失 部 分 将 由 控制 器 通过 Pod 模 板 予 以 创建 ， 而 多 出 的 副本 也 
将 由 控制 右 负 责 终止 及 删除 。 


Master 上 Nodes 
kube-controller-manager : 


Deployment Controller 
l Pod role:be-eshop 
站 Ca -一 -一 
eshop-deploy replicas:3 -可 | Pod | role:be-eshop 
label Ps 
i “a Pod role:be-eshop 


| selector role:be-eshop 


图 5-3 ”Deployment 控 制 右 示例 


5.1.3 ”Pod 模 板 资源 


PodTemplate 是 Kubernetes API 的 常用 资源 类 型 ， 常 用 于 为 控制 丹 
指定 自动 创建 Pod 资 源 对 象 时 所 需 的 配置 信息 。 因 为 要 内 般 于 控制 需 
中 使 用 ， 所 以 Pod 模 板 的 配置 信息 中 不 需要 apiVersion 和 和 kind 字段， 但 
除 此 之 外 的 其 他 内 容 与 定义 目 主 式 Pod 对 象 所 文 持 的 字段 几乎 完全 相 
同 ， 这 包括 metadata 和 spec 及 其 内 般 的 其 他 各 个 字段 。Pod 探 制 右 类 资 
源 的 spec 字 上 段 通 常 都 要 内 骨 replicas、selector 和 template 字 段 ， 其 中 
I ° 下面 是 一 个 定义 在 ReplicaSet 资 源 中 的 模 

资源 示例 : 


apiVersion: apps/vi 
kind: ReplicaSet 
metadata.: 
name: rs-example 
spec: 
replicas: 2 
selector: 
matchLabels: 
app: rs-demo 
template: 
metadata.: 
labels: 
app: rs-demo 
spec: 
containers: 
- name: myapp 
image: ikubernetes/myapp:v1 
ports: 
- name: http 
containerPort: 80 


如 上 示例 中 ，spec.template 字 段 在 定义 时 仅 给 出 了 metadata 和 spec 
两 个 字段 ， 它 的 使 用 方法 与 自主 式 Pod 资 源 完全 相同 。 后 面 讲 到 控制 
句 的 章 廊 时 会 反复 用 到 Pod 模 板 资源 。 


5.2 ReplicaSet 探 制 硕 


Kubernetes 较 早期 的 版 本 中 仅 有 ReplicationController 一 种 类 型 的 
Pod 控 制 器 ， 后 来 的 版 本 中 陆续 引入 了 更 多 的 控制 右 实 现 ， 这 其 中 束 
包括 用 来 取代 ReplicationController 的 新 一 代 实 现 ReplicaSet。 事 实 上 ， 
除了 额外 支持 基于 集合 (set-based) 的 标签 选择 器 ， 以 及 它 的 滚动 更 
新 (Rolling-Update) 机 制 要 基于 更 高 级 的 控制 Deployment 实 现 之 外 ， 
目前 的 ReplicaSet 的 其 余 功能 基本 上 与 ReplicationController 相 同 。 考虑 
到 Kubernetes 强 烈 推荐 使 用 ReplicaSet 控 制 嚣 ， 且 表示 
ReplicationController 不 久 后 即将 废弃 ， 这 里 就 重点 介绍 ReplicaSet 控 制 
器 。 


5.2.1 ReplicaSet 概 述 


ReplicaSet 〈 简 称 RS) 是 Pod 控 制 句 类 型 的 一 种 实现 ， 用 于 确保 由 
其 管控 的 Pod 对 象 副本 数 在 任 一 时 刻 都 能 精确 满足 期 望 的 数量 。 如 图 5- 
4 所 示 ，ReplicaSet 控 制 右 资源 局 动 后 会 但 找 集群 中 匹配 其 标签 选择 紫 的 
Pod 资 源 对 象 ， 当 前 活动 对 象 的 数量 与 期 鹿 的 数量 不 吻合 时 ， 多 则 删 
除 ， 少 则 通过 Pod 模 板 创建 以 补足 ， 等 Pod 资 源 副 本 数量 符合 期 望 值 后 
印 进 入 下 一 轮 和 解 循环 。 


Find pods 
matching the 


label selector 


Compare 
matched 


Create additional 
pod(s)from 
current template 


Too few Too many 
vs.desired 


pod count 


Delete the 
excess pod(s) 


图 5-4 ”ReplicaSet 的 控制 循环 (图 片 来 源 : 《Kubernetes in action》) 


ReplicaSet 的 副本 数量 、 标 签 选 择 占 甚至 古 Pod 模 板 都 可 以 随时 按 
需 进行 修改 ， 不 过 仅 改 动 期 望 的 副本 数量 会 对 现存 的 Pod 副 本 产生 直接 
影响 。 修 改 标签 选择 右 可 能 会 使 得 现 有 的 Pod 副 本 的 标签 变 得 不 再 匹 
配 ， 此 时 ReplicaSet 控 制 紫 要 做 的 不 过 是 不 再 计 入 它们 而 已 。 男 外 ， 在 
创建 完成 后 ，ReplicaSet 也 不 会 再 关注 Pod 对 象 中 的 实际 内 容 ， 因 此 Pod 
模板 的 改动 也 只 会 对 后 来 新 建 的 Pod 副 本 产生 影响 。 


Just enough 


. 相 比较 于 手动 创建 和 管理 Pod 资 源 来 说 ，ReplicaSet 能 够 实现 以 下 


功能 


:确保 Pod 资 源 对 象 的 数量 精确 反映 期 望 值 ，ReplicaSet 需 要 确保 由 
其 控制 运行 的 Pod 副 本 数量 精确 吻合 配置 中 定义 的 期 望 值 ， 否 则 束 会 目 
动 补 足 所 缺 或 终止 所 余 。 


-确保 Pod 健 康 运行 : 探测 到 由 其 管控 的 Pod 对 象 因 其 所 在 的 工作 节 
有 目 动 请 求 由 调度 器 于 其 他 工作 节点 创建 缺失 的 Pod 
副本 。 


:弹性 伸缩 : 业务 规模 因 各 种 原因 时 常 存在 明显 波动 ， 在 波峰 或 波 
合 期 间 ， 可 以 通过 ReplicaSet 控 制 絮 动态 调整 相关 Pod 资 源 对 象 的 数 
量 。 此 外 ， 在 必要 时 还 可 以 通过 HPA (HroizontalPodAutoscaler) 控制 
右 实 现 Pod 资 源 规模 的 目 动 伸缩 。 


5.2.2 ”创建 ReplicaSet 


类 似 于 Pod 资 源 ， 创 建 ReplicaSet 控 制 絮 对 象 同 样 可 以 使 用 YAML 
或 JSON 格 式 的 清单 文件 定义 其 配置 ， 而 后 使 用 相关 的 创建 命令 来 完成 
资源 创建 。 前 面 5.1.3 节 中 给 出 的 示例 清单 束 是 一 个 简单 的 ReplicaSet 的 
定义 。 它 也 由 kind、apiVersion、metadata、spec 和 status 这 5 个 一 级 字段 
组 成 ， 其 中 status 为 只 读 字 段 ， 因 此 需要 在 清单 文件 中 配置 的 仅 为 前 4 
个 字段 。 它 的 spec 字 段 一 般 般 套 使 用 以 下 几 个 属性 字段 。 


Teplicas<integer>: 期 望 的 Pod 对 象 副本 数 。 


selector<Object>: 当前 控制 锅 匹 配 Pod 对 象 副本 的 标签 选择 右 ， 
支持 matchLabels 和 matchExpressions 两 种 匹配 机 制 。 


template<Object>: 用 于 补足 Pod 副 本 数量 时 使 用 的 Pod 模 板 资 
源 。 


-minReadySecond<integer>s: 新 建 的 Pod 对 象 ， 在 局 动 后 的 多 长 时 
间 内 如 采 其 容器 未 发 生 朋 证 等 异种 情况 即 被 视 为 " 束 绪 ”>;， 默认 为 0 秒 ， 
表示 一 旦 就 绪 性 探测 成 功 ， 即 被 视 作 可 用 。 


将 5.1.3 广 中 的 示例 保存 于 资源 清单 文件 中 ， 例 如 rs- 
example.yaml， 而 后 即 可 使 用 如 下 命令 将 其 创建 : 


~]$ kubect1 apply -f rs-example.yaml 
replicaset.apps "rs-example" created 


集群 中 当前 没有 标签 为 “app: rs-demo” 的 Pod 资 源 存 在 ， 因 此 rs- 
example 需 要 按照 replicas 字 上 段 的 定义 创建 它们 ， 名 称 以 其 所 属 的 控制 器 
名 称 为 前 级 。 这 两 个 Pod 资 源 目前 都 处 于 ContainerCreating 状 态 ， 即 处 
于 容器 创建 过 程 中 ， 待 创建 过 程 完成 后 ， 其 状态 即 转 为 Running，Pod 
也 将 转变 为 “<READY”: 


~]# kubectl1 get pods -1] app=rs-demo 
NAME READY STATUS RESTARTS AGE 


rs-example-p66nv 0/1 ContainerCreating 0 8s 
rs-example-rdm7q 0/1 ContainerCreating 0 8s 


接 下 来 可 以 使 用 “kubectl get replicaset” 命 令 查 看 ReplicaSet 控 制 絮 
货源 的 相关 状态 。 下面 的 命令 结 采 显示 出 它 已 经 根据 请 单 中 配置 的 
ee 不 过 这 时 它们 尚未 创建 完成 ， 因 此 仍 
为 “READY?”: 


~]$ kubect1 get replicaset rs-example -0 wide 
NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTOR 
rs-example 2 2 0 2m nginx ikubernetes/myapp:v1i app=rs-demo 


经 由 控制 器 创建 与 用 户 自主 创建 的 Pod 对 象 的 功能 并 无 二 人 致 ， 但 
其 目 动 和 解 的 功能 在 很 大 程度 上 能 为 用 户 省 去 不 少 的 管理 精力 ， 这 也 
是 使 得 Kubernetes 系 统 之 上 的 应 用 程序 变 得 拥有 目 愈 能 力 的 主要 保 


障 。 


5.2.3 ”ReplicaSet 管 控 下 的 Pod 对 象 


5.2.2 世 中 创建 的 rc-example 通 过 标签 选择 器 将 拥有 “app=rs- 
demo” 标 签 的 Pod 资 源 收 归于 谭 下， 并 确保 其 数量 精确 符合 所 期 望 的 数 
目 ， 使 用 标签 选择 噩 显示 出 的 Pod 资 源 列表 也 能 验证 这 一 点 。 然 而 ， 
实际 中 存在 着 不 少 可 能 导致 Pod 对 象 数目 与 期 望 值 不 符合 的 可 能 性 ， 
如 Pod 对 象 的 意外 删除 、Pod 对 象 标签 的 变动 (已 有 的 Pod 资 源 变 得 不 
匹配 控制 妖 的 标签 选择 器 ， 或 者 外 部 的 Pod 资 源 标 签 变 得 匹配 到 了 挥 
制 器 的 标签 选择 器 ) 、 控 制 妖 的 标签 选择 右 变 动 ， 甚 至 是 工作 节点 故 
障 等 。ReplicaSet 控 制 右 的 和 解 循 环 过 程 能 够 实时 监控 到 这 类 异常 ， 并 
及 时 启动 和 人 解 操作 。 


1. 缺 少 Pod 副 本 


任何 原因 导致 的 相关 Pod 对 象 丢 失 ， 都 会 由 ReplicaSet 探 制 帮 目 动 
补足 。 例 如 ， 手 动 删除 上 面 列 出 的 一 个 Pod 对 象 ， 命 令 如 下 : 


~]$ kubect1 delete pods rs-example-rdm7q 
pod "rs-example-rdm7q" deleted 


再 次 列 出 相关 Pod 对 象 的 信息 ， 可 以 看 到 被 删除 的 rs-example- 
rdm7q 进 入 了 终止 过 程 ， 而 新 的 Pod 对 和 象 rs-example-l4gkp 正 在 被 rs- 
example 控 制 器 创建 : 


~]$ kubectl1 get pods -1 app=rs-demo -0 wide 
NAME READY TU 


STATUS RESTARTS AGE 
rs-example-14gkp 0/1 ContainerCreating 0 
rs-example-p66nv 1/1 Running 0 39m 
rs-example-rdm7q 0/1 Terminating 0 39m 


另外， 强行 修改 隶属 于 控制 器 rs-example 的 某 Pod 资 源 (匹配 于 标 
签 控 制 絮 ) 的 标签 ， 会 导致 它 不 再 被 控制 絮 作 为 副本 计数 ， 这 也 将 触 
发 控制 絮 的 Pod 对 象 副 本 缺失 补足 机 制 。 例 如 ， 将 rs-example-p66nv 的 
标签 app 的 值 置 空 : 


~]$ kubect1 Jabel pods rs-example-p66nv app= --overwrite 
pod "rs-example-p66nv" labeled 


列 出 rs-example 相 关 Pod 对 象 的 信息 ， 发 现 rs-example-p66nv 已 经 消 
失 不 见 ， 并 且 正 在 创建 新 的 对 象 副 本 。 


~]$ kubect1 get pods -1 app=rs-demo 

NAME READY STATUS RESTARTS AGE 
rs-example-4bqzv 0/1 ContainerCreating 0 2S 
rs-example-14gkp 1/1 Running 0 5m 


由 此 可 见 ， 修 改 Pod 资 源 的 标签 即 可 将 其 从 控制 器 的 管控 之 下 移 
出 ， 当 然 ， 修 改 后 的 标签 如 果 又 能 被 其 他 控制 器 资源 的 标签 选择 器 所 
命中 ， 则 此 时 它 又 成 了 隶属 于 男 一 控制 器 的 副本 。 如 采 修 改 其 标签 后 
的 Pod 对 象 不 再 隶属 于 任何 控制 毅 ， 那 么 它 束 将 成 为 目 主 式 Pod， 与 此 
前 手动 直接 创建 的 Pod 对 象 的 特性 相同 ， 即 误 删 除 或 所 在 的 工作 节点 
故障 都 会 造成 其 永久 性 的 消失 。 


2. 多 出 Pod 副 本 
一 旦 被 标签 选择 需 匹配 到 的 Pod 资 源 数 量 因 任何 原因 超出 期 望 


值 ， 多 余 的 部 分 都 将 被 控制 妖 目 动 删除 。 例 如 ， 为 pod-example 手 动 为 
其 添加 “app: rs-demo” 标 签 : 


~]$ kubect1 label pods pod-example app=rs-demo 
pod "pod-example" labeled 


再 次 列 出 相关 的 Pod 资 源 ， 可 以 看 到 rs-example 控 制 絮 启动 了 删除 
多 余 Pod 的 操作 ，pod-example 正 处 于 终止 过 程 中 : 


~]$ kubectl get pods -1 app=rs-demo 


NAME READY STATUS RESTARTS AGE 
pod-example 1/1 Terminating 0 2m 

rs-example-4bqzv 1/1 Running 0 17m 
rs-example-14gkp 1/1 Running 0 22m 


这 束 意 味 厦 ,任何 目 主 式 的 或 本 隶属 于 其 他 控制 右 的 Pod 资 源 其 
标签 变动 的 结果 一 旦 匹配 到 了 其 他 的 副本 数 足 额 的 控制 天 ， 就 会 导致 


这 类 Pod 资 源 被 删除 。 
查看 Pod 资 源 变动 的 相关 事件 


“kubectl describe replicasets” 命 令 可 打印 出 ReplicaSet 控 制 器 的 详细 
状态 ， 从 下 面 命令 结 采 中 Events 一 段 也 可 以 看 出 ，rs-example 执 行 了 
Pod 资 源 的 创建 和 删除 操作 ， 为 的 殉 是 确保 其 数量 的 精确 性 


~]$ kubectl1 describe replicasets/rs-example 


Name : rs-example 
Namespace: default 
Selector: app=rs-demo 
Labels: app=rs-demo 
Events: 
Type Reason Age ”From Message 


Gin SuccessfulCreate 21m replicaset-controller  _ Created pod: rs- 
example-14gkp 
Normal SuccessfulDelete 4m replicaset-controller Deleted pod: pod- 


example 
Normal SuccessfulCreate 26m replicaset-controller Created pod: rs- 


example-4bqzv 


事实 上 ，ReplicaSet 控 制 絮 能 对 Pod 对 象 数 日 的 异常 及 时 做 出 啊 
义 ， 是 因为 它 癌 API Server 注 册 监 听 〈watch) 了 相关 资源 及 其 列表 的 
变动 信息 ， 于 是 API Server 会 在 变动 发 生 时 立即 通知 给 相关 的 监听 客户 


阐 ® 


而 因 市 点 自身 故障 而 导致 的 Pod 对 象 丢失 ，ReplicaSet 控 制 帮 一 . 
会 使 用 补足 资源 的 方式 进行 处 理 ， 这 里 不 再 详细 说 明 其 过 程 。 有 兴 
Is 
验 其 处 理 过 程 。 


5.2.4 ”更 新 ReplicaSet 控 制 器 


ReplicaSet 控 制 絮 的 核心 组 成 部 分 是 标签 选择 絮 、 副 本 数量 及 Pod 
模板 ， 但 更 新 操作 一 般 是 围绕 replicas 和 template 两 个 字段 值 进行 的 ， 毕 
竞 改变 标 签 选择 器 的 需求 几乎 不 存在 。 改 动 Pod 模 板 的 定义 对 已 经 创建 
完成 的 活动 对 象 无 效 ， 但 在 用 户 逐 个 手动 天 闭 其 旧版 本 的 Pod 资 源 后 就 
能 以 新 代 旧 ， 实 现 控制 器 下 应 用 版 本 的 深 动 升级 。 男 外 ， 修 改 副 本 的 
数量 也 就 意味 着 应 用 规模 的 扩展 (提升 期 望 的 副本 数量 ) 或 收缩 ( 降 
低 期 望 的 副本 数量 ) 。 这 两 种 操作 也 是 系统 运 维 人 员 日 常 维护 工作 的 
重要 组 成 部 分 。 


1. 更 改 Pod 模 板 : 升级 应 用 


ReplicaSet 控 制 器 的 Pod 模 板 可 随时 按 需 修 改 ， 但 它 仅 影 响 这 之 后 
由 其 新 建 的 Pod 对 象 ， 对 已 有 的 副本 不 会 产生 作用 。 大 多 数 情 况 下 ， 用 
户 需 要 改变 的 通常 是 模板 中 的 容器 镜像 文件 及 其 相关 的 配置 以 实现 应 
用 的 版 本 升级 。 下 面 的 示例 清单 文件 片断 (rs-example-v2.yaml) 中 的 
风 > 之 前 版 本 (rs-example.yaml) 的 唯一 不 同 之 处 也 仅 在 于 镜像 文件 
忆 五 


containers: 
- name: nginx 
image: ikubernetes/myapp:v2 
ports: 
- name: http 
containerPort: 80 


对 新 版 本 的 清单 文件 执行 “kubectl apply” 或 “kubectl replace” 命 令 即 
可 完成 rs-example 控 制 器 资源 的 修改 操作 : 


~]$ kubect1l replace -f rs-example-v2.yaml 
replicaset.apps "rs-example" replaced 


不 过 ， 挖 制 器 rs-example 管 探 的 现存 Pod 对 象 使 用 的 仍然 是 原来 版 
本 中 定义 的 镜像 : 


~]$ kubect] get pods -1 app=rs-demo -ON 
custom-columns=Name :metadata.name, Image:spec.containers[0].image 
Name Image 
rs-example-4bqzv ikubernetes/myapp:vi 
rs-example-14gkp ikubernetes/myapp:v1 


此 时 ， 手 动 删除 控制 器 现 有 的 Pod 对 象 (或 修改 与 其 匹配 的 控制 器 
标签 选择 器 的 标签 ) ， 并 由 控制 右 基 于 新 的 Pod 模 板 自动 创建 出 足 额 的 
。 即 可 完成 一 次 应 用 的 升级 。 新 旧 更 奉 的 过 程 支 持 如 下 两 类 操 
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-一 次 性 删除 控制 器 相关 的 所 有 Pod 副 本 或 更 改 相关 的 标签 : 剧烈 更 
替 ， 可 能 会 导致 Pod 中 的 应 用 短 时 间 不 可 访问 (如 图 5-5 所 示 ) ; 生产 
实践 中 ， 此 种 做 法 不 可 取 。 


一 一 一 一 we > ya 一 一 
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图 5-5 ”直接 更 蔡 所 有 Pod 资 源 


-分 批 次 删除 日 有 的 Pod 副 本 或 更 改 其 标签 〈 竺 控制 右 补 足 后 再 删除 
男 一 批 ) : 滚动 更 替 ， 更 替 期 间 新 旧版 本 共存 (如 图 5-6 所 示 ) 


ReplicaSet ReplicaSet ReplicaSet 
PodTemplate:v1 PodTemplate:v2 PodTemplate:v2 | 
图 5-6 ”滚动 更 替 


例如 ， 这 里 采用 第 一 种 方式 进行 操作 ， 一 次 性 删除 rs-example 相 关 
的 所 有 Pod 副 本 : 


~]$ kubect] delete pods -1 app=rs-demo 
pod "rs-example-4bqzv" deleted 
pod "rs-example-14gkp" deleted 


再 次 列 出 rc-example 控 制 絮 相关 的 Pod 及 其 容 絮 镜像 版 本 时 可 以 友 
现 ， 使 用 新 版 本 镜像 的 Pod 已 经 创建 完成 : 


~]$ kubect] get pods -1 app=rs-demo -0o \ 
custom-columns=Name:metadata.name, Image:spec.containers[0].image 
Name Image 

rs-example-4bwqq ikubernetes/myapp:v2 

rs-example-hqgnh ikubernetes/myapp:v2 


必要 时 ， 用 户 还 可 以 将 Pod 模 板 改 回 旧 的 版 本 进行 应 用 的 “ 降 
级 ”或 “ 回 滚 ”， 它 的 操作 过 程 气 上述 过 程 基本 类 似 。 事 实 上 ， 修 改 Pod 
模板 时 ， 不 仅仅 能 蔡 换 镜像 文件 的 版 本 ， 甚 至 还 可 以 将 其 殖 换 成 其 他 
正在 运行 着 的 、 完 全 不 同 应 用 的 镜像 ， 只 不 过 此 类 需求 并 不 多 见 。 大 
同时 改动 的 还 有 Pod 模 板 中 的 其 他 字段 ， 那 么 在 新 旧 更 奉 的 过 程 中 ， 它 
们 也 将 随 之 被 应 用 。 


以 上 操作 只 为 说 明 应 用 部 署 的 方式 ， 实 际 使 用 时 还 需要 更 为 完善 
的 机 制 。 即 便 是 仅 执行 了 一 到 多 次 删除 操作 ， 手 动 执行 更 替 操 作 也 并 
非 一 项 轻松 的 任务 ， 科 和 运 的 是 ， 更 高 级 别 的 Pod 控 制 器 Deployment 能 够 
自动 实现 更 完善 的 滚动 更 新 和 回 滚 ， 并 为 用 户 提供 自 定 义 更 新 人 策略 的 
接口 。 而 且 ， 经 过 精心 组 织 的 更 新 操作 还 可 以 实现 诸如 监 绿 部 署 
(Blue/Green Deployment) 、 人 金 丝 徐 部 署 (Canary Deployment) 和 灰 度 
部 署 等 ， 这 些 内 容 将 在 后 面 章节 中 详细 展开 说 明 。 


2. 扩 容 和 缩 容 


改动 ReplicaSet 控 制 器 对 象 配 置 中 期 望 的 Pod 副 本 数量 (replicas 字 
段 ) 会 由 控制 器 实时 做 出 响应 ， 从 而 实现 应 用 规模 的 水 平 伸缩 。 
replicas 的 修改 及 应 用 方式 同 Pod 模 板 ， 不 过 ，kubectl 还 提供 了 一 个 专用 
的 子 命令 scale 用 于 实现 应 用 规模 的 伸缩 ， 它 文 持 从 资源 请 单 文件 中 获 
取 新 的 目标 副本 数量 ， 也 可 以 直接 在 命令 行 通过 “--replicas” 选 项 进行 读 
取 ， 例 如 将 rs-example 控 制 絮 的 Pod 副 本 数量 提升 至 5 个 : 


~]$ kubect] scale replicasets rs-example --replicas=5 
replicaset.extensions "rs-example" scaled 


由 下 面 显 示 的 rs-example 资 源 的 状态 可 以 看 出 ， 将 其 Pod 资 源 副 本 
数量 扩展 至 5 个 的 操作 已 经 成 功 完成 : 


~]$ kubect1l get replicasets rs-example 
NAME DESIRED CURRENT READY AGE 
rs-example 5 5 5 12h 


收缩 规模 的 方式 与 扩展 相同 ， 只 需要 明确 指定 目标 副本 数量 即 
可 。 例如 : 


~]$ kubect] scale replicasets rs-example --replicas=3 
replicaset.extensions "rs-example" scaled 


另外 ，kubectl scale 命 令 还 支持 在 现 有 Pod 副 本 数量 符合 指定 的 值 时 

才 执行 扩展 操作 ， 这 仅 需 要 为 命令 使 用 “--current-replicas” 选 项 即 可 。 例 

下 面 的 命 仿 表示 如 要 rs-example 目 前 的 Pod 副 本 数量 为 2， 束 将 其 扩 
至 4 个 


~]$ kubect] scale replicasets rs-example --current-replicas=2 --replicas=4 
error: Expected replicas to be 2, was 3 


但 由 于 rs-example 控 制 占 现存 的 副本 数量 古 3 个 ， 因 此 上 面 的 扩展 
操作 未 执行 并 返回 了 错误 提示 。 


© 注意 ”如 果 ReplicaSet 控 制 器 管控 的 是 有 状态 的 应 用 ， 例 如 
主 从 架构 的 Redis 集 群 ， 那 么 上 还 这 些 升级 、 降 级 、 扩 展 和 收缩 的 操作 
都 需要 精心 编排 和 参与 才能 进行 ， 不 过 ， 这 也 在 一 定 程度 上 降低 了 
Kubernetes 容 器 编排 的 价值 和 意义 。 好 在 ， 它 提供 了 StatefulSet 资 源 来 
应 对 这 种 需求 ， 因 此 ，ReplicaSet 通 和 常 仅 用 于 管理 无 状态 的 应 用 ， 如 
HTTP 服 务 程序 等 。 


5.2.5 ”删除 ReplicaSet 控 制 磊 资源 


使 用 kubectl delete 命 令 删 除 ReplicaSet 对 象 时 默认 会 一 并 删除 其 管 
探 的 各 Pod 对 象 。 有 时 ， 考 虑 到 这 些 Pod 资 源 未 必 由 其 创建 ， 或 者 即便 
由 其 创建 却 也 并 非 其 目 身 的 组 成 部 分 ， 故 而 可 以 为 命令 使 用 “-- 
cascade=false” 选 项 ， 取 消 级 联 ， 删 除 相 关 的 Pod 对 象 ， 这 在 Pod 资 源 后 
续 可 能 会 再 次 用 到 时 尤为 有 用 。 例 如 ， 删 除 rs 控制 器 rs-example: 


~]$ kubectl1 delete replicasets rs-example --cascade=false 
replicaset.extensions "rs-example" deleted 


删除 操作 完成 后 ， 此 前 由 rs-example 控 制 絮 管控 的 各 Pod 对 象 仍 处 
， 但 它们 变 成 了 目 主 式 Pod 资 源 ， 用 户 需 要 上 自行 组 织 和 维 
它们 。 


名 提示 “后 续 讲 到 的 各 Pod 探 制 如 的 删除 方式 都 与 ReplicaSet 
类 似 ， 这 里 就 不 再 分 别 进行 说 明了 。 


尽管 ReplicaSet 控 制 右 功能 强大 ， 但 在 实践 中 ， 它 却 并 非 是 用 户 直 
| 外 右 ， 而 十 要 由 比 其 更 局 一 级 抽象 的 Deployment 控 制 絮 对 
碳 用 。 


5.3 Deployment 控制 妖 


Deployment (简写 为 deploy) 是 Kubernetes 控 制 器 的 又 一 种 实现 ， 
它 构 建 于 ReplicaSet 控 制 絮 之 上 ， 可 为 Pod 和 ReplicaSet 痪 禹 源 提供 声明 式 
更 新 。 相 比较 而 言 ，Pod 和 ReplicaSet 是 较 低 级 别 的 资 和 源 . 它们 很 少 被 
直接 使 用 。Deployment、ReplicaSet 和 Pod 的 关系 如 图 5-7 所 示 。 
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图 5-7 Deployment 、 ReplicaSets 和 Pods 


Deployment 控 制 絮 资源 的 主要 职责 同样 是 为 了 你 证 Pod 资 源 的 健康 
， oo， 分 功能 均 可 通过 调用 ReplicaSet 控 制 器 来 实现 ， 同 时 还 增 
lya 分 特性 


.事件 和 状态 查看 : 必要 时 可 以 查看 Deployment 对 象 升 级 的 详细 进 
度 和 状态 。 


- 回 滚 : 升级 操作 完成 后 发 现 问题 时 ， 文 持 使 用 回 浚 机 制 将 应 用 返 
回 到 前 一 个 或 由 用 户 指定 的 历史 记录 中 的 版 本 上 。 


版 本 记录 : 对 Deployment 对 象 的 每 一 次 操作 都 子 以 保存 ， 以 供 后 
续 可 能 执行 的 回 滚 操作 使 用 。 


暂停 和 局 动 : 对 于 每 一 次 升级 ， 都 能 够 随时 暂停 和 局 动 。 


.多 种 目 动 更 新 方案 ; 即 重建 更 新 机 制 ， 全 面 停 
止 、 删 除 上 日 有 的 Pod 后 用 新 版 本 蔡 代 ; 另 一 个 是 RollingUpdate， 即 滚动 


升级 机 制 ， 逐 步 蔡 换 旧 有 的 Pod 至 新 的 版 本 。 


5.3.1 创建 Deployment 


Deployment 是 标准 的 Kubernetes API 资 源 ， 它 建构 和 于 ReplicaSet 质 
源 之 上 ， 于 是 其 spec 字 段 中 舱 套 使 用 的 字段 包含 含 了 ReplicaSet 控 制 右 支 
持 的 replicas、 \ template 和 minReadySeconds， 它 也 正 是 利用 这 
些 信 息 完 成 了 其 二 级 资源 ReplicaSet 对 象 的 创建 。 下 面 是 一 个 
Deployment 探 制 辟 资 源 的 配置 清单 示例 : 


apiVersion: apps/vi1 
kind: Deployment 
metadata: 
name: myapp-deploy 
spec: 
replicas: 3 
selector: 
matchLabels: 
app: myapp 
template: 
metadata.: 
labels: 
app: myapp 
spec: 
containers: 
- name: myapp 
image: ikubernetes/myapp:v1 
ports: 
- containerPort: 80 
name: http 


上 面 的 内 容 显 示 出 ， 除 了 控制 器 类 型 和 名 称 之 外 ， 它 与 前 面 
ReplicaSet 挥 制 占 示例 中 的 内 容 几 乎 没有 什么 不 同 。 下 面 在 集群 中 创建 
以 了 解 它 的 工作 方式 : 


~]$ kubectl1 apply -f myapp-deploy.yaml --record 
deployment ,apps "myapp-deploy" created 


“kubectl get AR 以 列 出 创建 的 Deployment 对 和 象 
myapp-deploy 及 其 相关 的 信息 。 下 面 显 示 的 字段 中 ，UP-TO-DATE 表 
示 已 经 达到 期 望 状态 的 poq 副 本 数量 ，AVAILABLE 则 表示 当前 处 于 可 
用 状态 的 应 用 程序 的 数量 : 


~]$ kubect1 get deployments myapp-deploy 
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE 
myapp-deploy 3 3 3 3 13s 


Deployment 控 制 如 会 目 动 创建 相关 的 ReplicaSet 控 制 器 资源 ， 并 
以 *[DEPLOYMENTNAME]-[POD-TEMPLATE-HASH-VALUE]" 格 式 
为 其 命名 ， 其 中 的 hash 值 由 Deployment 控 制 器 自动 生成 。 由 
Deployment 创 建 的 ReplicaSet 对 象 会 目 动 使 用 相同 的 标签 选择 妖 ， 
此 ， 可 使 用 类 似 如 下 的 命令 查看 其 相关 的 信息 : 


~]$ kubect1 get replicasets -1 app=myapp 
NAME DESIRED CURRENT READY AGE 
myapp-deploy-86b4b8c75d 3 3 3 37S 


相关 的 Pod 对 和 象 的 信息 可 以 用 相似 的 命令 进行 获取 。 下 面 的 命令 
结果 中 ，Pod 对 象 的 名 称 a 命名 格式 ， 它 以 
ReplicaSet 控 制 絮 的 名 称 为 前 级 ， 后 跟 5 位 随机 字符 : 


~]$ kubectl1 get pods -1 app=myapp 


NAME READY STATUS RESTARTS AGE 
myapp-deploy-86b4b8c75d-7dtxn 1/1 Running 0 46S 
myapp-deploy-86b4b8c75d-hdw9z 1/1 Running 0 46S 
myapp-deploy-86b4b8c75d-w4svj 1/1 Running 0 46S 


由 此 印证 了 Deployment 借 助 于 ReplicaSet 管 理 Pod 资 源 的 机 制 ， 于 
是 可 以 得 知 ， 其 大 部 分 管理 操作 与 ReplicaSet 相 同 。 人 过， Deployment 
也 有 ReplicaSet 所 不 具有 的 部 分 高 级 功能 ， 这 其 中 最 著名 的 当 数 其 自动 
滚动 更 新 的 机 制 。 


5.3.2 ”更 狐 策 略 


如 前 所 述 ，ReplicaSet 控 制 器 的 应 用 更 新 需要 手动 分 成 多 步 并 以 特 
定 的 次 序 进 行 ， 过 程 索 杂 且 容易 出 错 ， 而 Deployment 却 只 需要 由 用 户 
指定 在 Pod 模 板 中 要 改动 的 内 容 ， 例 如 容器 镜像 文件 的 版 本 ， 余 下 的 步 
又 可 交 由 其 自动 完成 。 同 样 ， 更 新 应 用 程序 的 规模 也 只 需要 修改 期 望 
的 副本 数量 ， 余 下 的 事情 交 给 Deployment 挥 制 絮 即 林 。 


Deployment 控 制 器 详细 信息 中 包含 了 其 更 新 策略 的 相关 配置 信 


息 ， 如 myapp-deploy 控 制 絮 资源 “kubectl describe” 命 令 中 输出 的 
StrategyType、RollingUpdateStrategy 字 段 等 


~]$ kubect]l describe deployments myapp-deploy 


Name : myapp-deploy 

Namespace: default 

CreationTimestamp: Fri, 02 Mar 2018 09:57:06 +0800 

Labels: app=deploy-demo 

Annotations: deployment .kubernetes.io/revision=1 

Selector: app=myapp 

Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 
unavailable 

StrategyType: RollingUpdate 

MinReadySeconds: 0 


RollingUpdateSstrategy: 25% max unavailable, 25% max Surge 


OldReplicasets: <none> 
NewReplicaSet: myapp-deploy-86b4b8c75d (3/3 replicas created) 


Deployment 控 制 器 支持 两 种 更 新 策 略 : 深 动 更 新 (rolling update) 
和 重新 创建 (recreate)y ， 默 认为 深 动 更 新 。 重 新 创建 更 新 类 似 于 前 文 
中 ReplicaSet 的 第 一 种 更 新 方式 ， 即 首先 删除 现 有 的 Pod 对 象 ， 而 后 由 
控制 器 基于 新 模板 重新 创建 出 新 版 本 资源 对 象 。 通 常 ， 只 应 该 在 应 用 
的 新 旧版 本 不 兼容 (如 依赖 的 后 端 数 据 库 的 schema 不 同 且 无 法 兼容 ) 
时 运行 时 才 会 使 用 recreate 策 略 ， 因 为 它 会 导致 应 用 玲 换 期 间 暂 时 不 可 
用 ， 好 处 在 于 它 不 存在 中 间 状 态 ， 用 户 访问 到 的 要 么 是 应 用 的 新 版 
本 ， 要 么 是 旧版 本 。 


深 动 升级 是 默认 的 更 新 策略 ， 它 在 删除 一 部 分 旧版 本 Pod 资 源 的 同 
时 ， 补 充 创 建 一 部 分 新 版 本 的 Pod 对 象 进行 应 用 升级 ， 其 优势 是 升级 期 
间 ， 窑 吕 中 应 用 提供 的 服务 不 全 中 上 但 要 求 应 用 程序 能 够 应 对 新 旧 


版 本 同时 工作 的 情形 ， 例 如 新 旧版 本 兼容 同一 个 数据 库 方案 等 。 不 
间 ， 不 同 客 户 问 得 到 的 啊 应 内 容 可 能 会 来 目 不 同 版 本 
» VW. 9 


Deployment 控 制 器 的 滚动 更 新 操作 并 非 在 同一 个 ReplicaSet 控 制 絮 
对 象 下 删除 并 创建 Pod 资 源 ， 而 是 将 它们 分 置 于 两 个 不 同 的 控制 絮 之 
下 : 旧 控 制 器 的 Pod 对 象 数量 不 断 减 少 的 同时 ， 新 控制 絮 的 Pod 对 象 数 
量 不 断 增 加 ， 直 到 旧 控 制 器 不 再 拥有 Pod 对 象 ， 而 新 控制 絮 的 副本 数量 
变 得 完全 符合 期 望 值 为 止 ， 如 图 5-8 所 示 。 


、 cn A Ss 、 / Fe 、 f 
/ \ f h 4 Ms 1/ 
| | (IE (ES | | 
7 J \ 4 \ \ 4 & 
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图 5-8 Deployment 的 滚动 更 新 


滚动 更 新 时 ， 应 用 升级 期 间 还 要 确保 可 用 的 Pod 对 象 数 量 不 低 于 某 
国 值 以 确保 可 以 持续 处 理 客 户 端的 服务 请 求 ， 变 动 的 方式 和 Pod 对 象 的 
数量 范围 将 通过 spec.strategyrollingUpdate.maxSurge 和 
spec.strategy.rollingUpdate.maxUnavailable 两 个 属性 协同 进行 定义 ， 它 们 
的 功用 如 图 5-9 所 示 。 


-maxSurge: 指定 升级 期 间 存在 的 总 Pod 对 和 象 数 量 最 多 可 超出 期 望 值 
的 个 数 ， 其 值 可 以 是 0 或 正 整 数 ， 也 可 以 是 一 个 期 望 值 的 百分比 ; 例 
如 ， 如 果 期 望 值 为 3， 当 前 的 属性 值 为 1， 则 表示 Pod 对 象 的 总 数 不 能 超 


过 4 个 。 


:maxUnavailable 升级 期 间 正 常 可 用 的 Pod 副 本 数 (包括 新 旧版 
本 ) 最 多 不 能 低 于 期 望 数值 的 个 数 ， 其 值 可 以 是 0 或 正 整数 ， 也 可 以 是 
一 个 期 望 值 的 百分比 ;默认 值 为 1， 该 值 意味 着 如 果 期 望 值 是 3， 则 升 
级 期 间 至 少 要 有 了 两 个 Pod 对 象 处 于 正常 提供 服务 的 状态 。 


delete v1 pod waituntil delete twovl wait until 

& create two both are pods & create it 1s 

# of V2 pods avaliable one v2 pod available 

pods AZ 
A 


maxSurge=1 . . 
desired replica 


count=3 


time 


2 avallable 4 available 2 available 3 available 
2 unavailable 1 unavailable 


图 5-9 maxSurge 和 maxUnavailable 的 作用 方式 (图 片 来 源 : 


《Kubernetes in action》 ) 


O 注意 “maxSurge 和 maxUnavailable 属 性 的 值 不 可 同时 为 0， 否 
则 Pod 对 和 象 的 副本 数量 在 符合 用 户 期 望 的 数量 后 无 法 做 出 合理 变动 以 进 
行 滚动 更 新 操作 。 


配置 时 ， 用 户 还 可 以 使 用 Deplpoyment 控 制 器 的 
spec.minReadySeconds 属 性 来 控制 应 用 升级 的 速度 。 新 旧 更 替 过 程 中 ， 
新 创建 的 Pod 对 象 一 旦 成 功 响 应 束 绪 探测 即 被 视 作 可 用 ， 而 后 即 可 立即 
开始 下 一 轮 的 蔡 换 操作 。 而 spec.minReadySeconds 能 够 定义 在 新 的 Pod 
对 象 创 建 后 至 少 要 等 竺 多久 才 会 将 其 视 作 束 绪 ， 在 此 期 间 ， 更 新 操作 
会 被 阻塞 。 因 此 ， 它 可 以 用 来 让 Kubernetes 在 每 次 创建 出 Pod 资 源 后 都 
要 等 上 一 段 时 长 后 再 开始 下 一 轮 的 更 替 ， 这 个 时 间 长 度 的 理想 值 是 等 
到 Pod 对 象 中 的 应 用 已 经 可 以 接受 并 处 理 请 求 流量 。 事 实 上 ， 一 个 精心 
设计 的 等 待 时 长 和 就 绪 性 探测 能 让 Kubernetes 系 统 规 避 一 部 分 因 程 序 
Bug 而 导致 的 升级 故障 。 


Deployment 控 制 右 也 文 持 用 户 保留 其 滚动 更 新 历史 中 的 旧 
ReplicaSet 对 象 版 本 ， 如 图 5-10 所 示 ， 这 赋予 了 控制 硕 进 行 应 用 回访 的 
能 力 : 用 户 可 按 需 回 滚 到 指定 的 历史 版 本 。 探 制 器 可 保存 的 历史 和 版 本 
数量 由 “spec.revisionHistoryLimit” 属 性 进行 定义 。 当 然 ， 也 只 有 保存 于 


revision 历 史 中 的 ReplicaSet 版 本 可 用 于 回 滩 ， 因 此 ， 用 户 要 习惯 性 地 在 
更 新 操作 时 指定 保留 旧版 本 。 


| revision 1 revision 2 revision 3 revision 4 revision 5 


: | ReplicaSet | | ReplicaSet | | ReplicaSet | | ReplicaSet | | ReplicaSet . 


current revision 


ma 


revision history 


| Deployment | 


图 5-10 ”Deployment 的 版 本 历史 记录 


注意 ”为 了 保存 版 本 升级 的 历史 ， 需 要 在 创建 Deployment 对 
象 时 于 命令 中 使 用 “--record” 选 项 。 


尽管 滚动 更 新 以 方 约 系 统 资 源 闭 称 ， 但 它 也 存在 一 些 劣势 。 直 接 
改动 现 有 环境 ， 会 使 系统 引入 不 确定 性 风险 ， 而 且 升级 过 程 出 现 问 题 
后 ， 执 行 回 深 操 作 也 会 较为 缓慢 。 有 鉴于 此 ， 金 丝 涂 部署 可 能 是 较为 
理想 的 实现 方式 ， 当 然 ， 如 末 不 考虑 系统 资源 的 可 用 性 ， 那 么 传统 的 
监 绿 部 署 也 古 不 错 的 选择 。 


5.3.3 ”升级 Deployment 


修改 Pod 模 板 相 关 的 配置 参数 便 能 完成 Deployment 控 制 器 资源 的 更 
新 。 由 于 是 声明 式 配 置 ， 因 此 对 Deployment 控 制 絮 资源 的 修改 尤其 适 
合 使 用 apply 和 patch 命 令 来 进行 ， 当然， 如 果 仅 是 修改 容器 镜像 ，“set 
image” 命 令 更 为 易 用 。 

接 下 来 通过 更 狐 此 前 创建 的 Deployment 探 制 左 deploy-example 来 了 
解 更 新 操作 过 程 的 执行 细节 ， 为 了 使 得 升级 过 程 更 易于 观测 ， 这 里 先 
使 用 “kubectl patch” 命 令 为 其 spec.minReadySeconds 字 段 定 义 一 个 等 符 
时 长 ， 例 如 5s: 


~]$ kubectl1 patch deployments myapp-deploy -p '{"spec": {"minReadySeconds": 5}}' 
deployment .extensions "myapp-deploy" patched 


patch 命 令 的 补丁 形式 为 JSON 格 式 ， 以 -p 选 项 指定 ， 上 面 命令 中 
的 '{"spec": {"minReadySeconds": 5}}' 表 示 设 置 spec.minReadySeconds 
属性 的 值 。 若 要 改变 myapp-deploy 中 myapp 容 器 的 镜像 ， 也 可 使 用 
patch 命 令 ， 如 '{"spec": {"containers": 
["name": "myapp"，"image""ikubernetes/myapp: V2"}}， 不 过 ， 修 改 
容 磊 镜像 有 更 为 们 单 的 专用 命令 “set image”。 

/SS 
>» 注意 ”修改 Deployment 控 制 右 的 minReadySeconds、replicas 
和 strategy 等 字段 的 值 并 不 会 触发 Pod 资 源 的 更 新 操作 ， 因 为 它们 不 属 
于 模板 的 内 模 字 段 ， 对 现存 的 Pod 对 象 不 产生 任何 影响 。 


接着 ， 使 用 “ikubernetes/myapp: V2” 锐 像 文件 修改 Pod 模 板 中 的 
myapp 容 器 ， 启 动 Deployment 控 制 器 的 滚动 更 新 过 程 : 


~]$ kubectl1 set image deployments myapp-deploy myapp=ikubernetes/myapp:v2 
deployment .apps "myapp-deploy" image updated 


“kubectl rollout status” 命 令 可 用 于 打印 滚动 更 新 过 程 中 的 状态 信 


ET 


~]$ kubectl1 rollout status deployments myapp-deploy 


另外， 还 可 以 使 用 “kubectl get deployments--watch” 命 令 监 探 其 更 
杀 过 程 中 Pod 对 和 象 的 变动 过 程 : 


~]$ kubectl1 get deployments myapp-deploy --watch 


深 动 更 新 时 ，myapp-deploy 控 制 器 会 创建 一 个 新 的 ReplicaSet 控 制 
俐 对象 来 管控 狐 版 本 的 Pod 对 象 ， 升 级 完成 后 ， 旧 版 本 的 ReplicaSet 会 
保留 在 历史 记录 中 ， 但 其 此 前 的 管控 Pod 对 象 将 会 被 删除 。 


~]$ kubect1 get replicasets -1 app=myapp 


NAME DESIRED CURRENT READY AGE 
myapp-deploy-79859f456c 3 3 3 1m 
myapp-deploy-86b4b8c75d 0 0 0 7Zm 


myapp-deploy 控 制 絮 管控 的 Pod 资 源 对 象 也 将 随 之 更 新 为 以 新 | 2 
ReplicaSet 名 称 “myapp-deploy-79859f456c" 为 前 绥 的 Pod 副 本 ， 命 令 
果 如 下 所 示 : 


~]$ kubectl1 get pods -1 app=myapp 


NAME READY STATUS RESTARTS AGE 
myapp-deploy-79859f456c-29rqw 1/1 Running 0 16m 
myapp-deploy-79859f456c-fhhwf 1/1 Running 0 15m 
myapp-deploy-79859f456c-h4n9d 1/1 Running 0 15m 


由 于 已 经 处 于 READY 状 态 ， 因 此 上 面 命 令 列 出 的 任 一 Pod 锅 雁 源 均 
可 正常 同 用 户 提 供 相关 服务 ， 例 如 ， 在 集群 内 任 一 能 使 用 kubectl 的 节 
点 访问 myapp- A sl 


~]$ curl $(kubectl1 get pods myapp-deploy-79859f456c-29rqw -0 go-template={{. 
status.podIp}}) 
Hello MyApp | Version: v2 | <a href="hostname.html">Pod Name</a> 


5.3.4 金 丝 御 发 布 


Deployment 控 制 器 还 支持 自 定义 控制 更 新 过 程 中 的 深 动 六 答 ， 

如 “暂停 ” (pause) 或 “继续 ” (resume) 更 新 操作 ， 尤 其 是 借助 于 前 文 
讲 到 的 maxSurge 和 maxUnavailable 属 性 还 能 实现 更 为 精巧 的 过 程控 制 。 
比如 ， 待 第 一 批 新 的 Pod 资 源 创 建 完 成 后 立即 暂停 更 新 过 程 ， 此 时 ， 仅 
存在 一 小 部 分 新 版 本 的 应 用 ， 主 体 部 分 还 是 旧 的 版 本 。 然 后 ， 再 根据 
用 刀 符 年 铺 ， 心 往 选 出 小 部 分 用 户 的 请 求 路 由 至 新 版 本 的 Pod 应 用 ， 并 持 

续 观 察 其 是 否 能 稳定 地 按期 望 的 方式 运行 。 确 定 没有 问题 后 再 继续 完 
成 余下 Pod 资 源 的 滚动 更 新 ， 否则 立即 回 滚 更 新 操作 。 这 便 是 所 谓 的 金 
丝 雀 发布 (Canary Release) ， 如 图 5-11 所 示 。 


Loadbalancer 


图 5-11 金 丝 雀 发布 (图 片 来 源 : http://blog.christianposta.com ) 
拓展 知识 ， 矿 井中 的 金 丝 答 


17 世 纪 ， 英 国 矿井 工人 发 现 ， 金 丝光 对 瓦斯 这 种 气体 十 分 敏感 。 
空气 中 哪怕 有 极其 微量 的 瓦斯 气体 ， 金 丝 涛 也 会 停止 歌唱 ; 当 瓦 斯 售 
量 超过 一 定 限度 时 ， 人 类 依旧 毫 无 察觉 ， 而 金 丝 省 却 早 已 毒 发 身亡 。 
当时 在 采矿 设备 相对 人 簿 陋 的 条 件 下 ， 工 人 们 每 次 下 井 都 会 市 上 一 只 金 
丝竹 作为 瓦斯 检测 工具 ， 以 便 在 危险 状况 下 紧急 撤离 。 


直接 发 布 新 应 用 版 本 的 在 线 发 布 形式 中 ， 金 丝竹 发 布 是 一 种 较为 
妥当 的 方式 。 不 过 ， 这 里 只 涉及 其 部 署 操 作 的 相关 步骤 ， 发 布 方式 则 
通常 依赖 于 具体 的 环境 设置 。 接 下 来 说 明 如 何在 Kubernetes 上 使 用 
Deployment 探 制 器 实现 金 丝 徐 部 署 。 


为 了 尽 可 能 地 降低 对 现 有 系统 及 其 容量 的 影响 ， 金 丝 誉 发 布 过 程 
通常 建议 采用 “ 先 添加 、 再 删除 ， 且 可 用 Pod 资 源 对 象 总 数 不 低 于 期 望 
值 ”* 的 方式 进行 。 首 次 添加 的 Pod 对 和 象 数量 取决 于 其 接 入 的 第 一 批 请 求 
的 规则 及 单个 Pod 的 承载 能 力 ， 视 具体 需求 而 定 ， 为 了 能 够 更 简单 地 说 
明 问 题 ， 授 下 来 采用 前 批 添 加 1 个 Pod 资 源 的 方式 。 将 Deployment 控 制 
铝 的 maxSurge 属 性 的 值 设置 为 1， 并 将 maxUnavailable 属 性 的 值 设 置 为 
0: 


~]$ kubect1 patch deployments myapp-deploy \ 

-p '{"spec": {"strategy":{"rollingUpdate": {"maxSurge": 1, "maxUnavailable": 
0}}}}" 

deployment .extensions "myapp-deploy" patched 


接 下 来 ， 启 动 myapp-deploy 控 制 器 的 更 新 过 程 ， 在 修改 相应 容器 的 
镜像 版 本 后 立即 暂停 更 新 进度 ， 它 会 在 局 动 第 一 批 新 版 本 Pod 对 象 的 创 
建 操 作 之 后 转 为 暂停 状态 。 需 要 注意 的 是 ， 这 里 之 所 以 能 够 在 第 一 批 
更 新 启动 后 就 暂停 ， 有 赖 于 此 前 为 maxReadySeconds 必 性 设置 的 时 长 ， 
因此 用 户 要 在 更 新 命令 启动 后 的 此 时 长 指定 的 时 间 范 围 内 启动 暂停 操 
作 ， 其 执行 过 程 如 图 5-12 所 示 。 当 然 ， 对 kubect 命 令 来 说 ， 也 可 以 直接 
以 “<&&ce" 符 号 在 Shell 中 连接 两 个 命令 : 


~]$ kubectl] set image deployments myapp-deploy myapp=ikubernetes/myapp:v3 \ 
&& kubect1 rollout pause deployments myapp-deploy 

deployment.apps "myapp-deploy" image updated 

deployment.apps "myapp-deploy" paused 
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图 5-12 ”和 暂停 Deployment 演 动 更 新 


通过 其 状态 查看 命令 可 以 看 到 ， 在 创建 完 一 个 新 版 本 的 Pod 资 源 后 
滚动 更 新 操作 “暂停 ”， 


~]$ kubect] rollout status deployments myapp-deploy 
Waiting for rollout to finish: 1 out of 3 new replicas have been updated... 


相关 的 Pod 列 表 也 可 能 显示 旧版 本 的 ReplicaSet 的 所 有 Pod 副 本 仍 在 
正常 运行 ， 狐 版 本 的 ReplicaSet 也 包含 一 个 Pod 副 本 ， 但 最 多 不 超过 期 
望 值 1 个 ，myapp-deploy 原 有 的 期 望 值 为 3， 因 此 忌 数 不 超过 4 个 。 此 
时 ， 通 过 Service 或 mgress 资 源 及 相关 路 由 策略 等 设 定 ， 即 可 将 一 部 分 
用 户 的 流量 引入 到 这 些 Pod 之 上 进行 发 布 验证 。 运 行 一 段 时 间 后 ， 如 果 
确认 没有 问题 ， 即 可 使 用 “kubectl rollout resume” 命 令 继续 此 前 的 深 动 更 
源 过 程 : 


~]$ kubect] rollout resume deployments myapp-deploy 
deployment.apps "myapp-deploy" resumed 


“kubectl rollout status” 命 令 监控 到 浚 动 更 新 过 程 完 成 后 ， 即 可 通过 
myapp-deploy 控 制 器 及 其 ReplicaSet 和 和 Pod 对象 的 相关 信息 来 了 解 其 结果 
站 大 


O 
/Un 


然而 ， 如 采 “ 金 丝 禾 ?过 险 甚 至 遭遇 不 仁 ， 那 么 回 滚 操 作 便 成 了 接 
下 来 的 当 紧 任务 。 


5.3.5 回 滚 Deployment 控 制 硕 下 的 应 用 发 布 


若 因 各 种 原因 导致 深 动 更 新 无 法 正常 进行 ， 如 镜像 文件 获取 失 
败 、“ 金 丝 仪 ”遇险 等 ， 则 应 该 将 应 用 回 深 到 之 前 的 版 本 ， 或 者 回 深 到 
由 用 户 指 定 的 历史 记录 中 的 版 本 。Deployment 控 制 紫 的 回 深 操 作 可 使 
用 “kubectl rollout undo” 命 令 完 成 例如， 下面 的 命令 可 将 myapp- 
deploy 回 滚 至 此 前 的 版 本 : 


~]$ kubectl1 rollout undo deployments myapp-deploy 
deployment.apps "myapp-deploy" 


等 回 深 完 成 后 ， 验 证 myapp-deploy 的 ReplicaSet 控 制 絮 对 象 是 否 已 
恢复 到 指定 的 历史 版 本 以 确 你 其 回 深 正 常 完成 。 在 “kubectl] rollout 
undo” 命 令 上 使 用 “--to-revision” 选 项 指定 revision 号 码 即 可 回 深 到 历史 
特定 版 本 ， 例 如 ， 假 设 myapp-deploy 包 含 如 下 的 revision 历 史记 录 : 


~]$ kubectl1 rollout history deployments myapp-deploy 
deployments "myapp-deploy" 
REVISION CHANGE-CAUSE 


1 kubect] patch deployments myapp-deploy --patch={"spec": {"minReady- 
Seconds": 5}} 

2 kubect] patch deployments myapp-deploy --patch={"spec": {"strategy": 
{"rollingUpdate": {"maxSurge": 1, "maxUnavailable": 0}}}} 

3 kubect] set image deployments myapp-deploy myapp=ikubernetes/myapp:v3 

4 kubect] set image deployments myapp-deploy myapp=ikubernetes/myapp:v4 


若 要 回 深 到 号 码 为 2 的 revision 记 录 ， 则 使 用 如 下 命令 即 可 完成 : 


~]$ kubectl1 rollout undo deployments myapp-deploy --to-revision=2 
deployment.apps "myapp-deploy" 


回 深 操作 中 ， 其 revision 记 录 中 的 信息 会 发 生变 动 ， 回 滚 操作 会 被 
当 作 一 次 深 动 更 新 妃 加 进 历史 记录 中 ， 而 被 回 深 的 条 目 则 会 被 删除 。 
需要 注意 的 是 ， 如 有 果 此 前 的 深 动 更 新 过 程 处 于 “暂停 ”状态 ， 那 么 回 深 
控 作 整 需 要 先 将 Pod 模 板 的 版 本 改 回 到 之 前 的 版 本 ， 然 后 “继续 ”更 新 ， 
人 否则， 其 将 一 直 处 于 暂停 状态 而 无 法 回 湾 。 


5.3.6 ”扩容 和 纵容 


通过 修改 .spec.replicas 即 可 修改 Deployment 探 制 右 中 Pod 资 源 的 副 
本 数量 ， 它 将 实时 作用 于 控制 右 并 直接 生效 。Deployment 控 制 器 是 声 
明 式 配置 ，replicas 属 性 的 值 可 直接 修改 资源 配置 文件 ， 然 后 使 
用 “kubectl apply” 进 行 应 用 ， 也 可 以 使 用 “kubectl edit* 对 其 进行 实时 修 
改 。 而 前 一 种 方式 能 够 将 修改 结 采 了 予以 长 期 留存 。 


另外 , “kubectl scale” 是 专用 于 扩展 某 些 控制 器 类 型 的 应 用 规模 的 
命令 ， 包 括 Deployment 和 Job 等 。 而 Deployment 通 过 ReplicaSet 控 制 其 
pod 资 源 ， 因 此 扩 缩 容 的 方式 是 相同 的 ， 除 了 命令 直接 作用 的 资源 对 
象 有 所 不 同 之 外 ， 这 里 不 再 对 其 进行 展开 说 明 。 


5.4 DaemonSet 挖 制 妖 


DaemonSet 十 Pod 控 制 占 的 义 一 种 实现 ， 用 于 在 集群 中 的 全 部 市 上 
上 同时 运行 一 份 指定 的 Pod 资 源 副本 ， 后 续 新 加 入 集群 的 工作 市 点 也 
会 目 动 创建 一 个 相关 的 Pod 对 象 ， 当 从 集群 移 除 节点 时 ， 此 类 Pod 对 象 
也 将 补 目 动 回 收 而 无 须 重 建 。 管 理 员 也 可 以 使 用 节点 选择 器 及 市 点 标 
签 指 定 仅 在 部 分 具有 特定 特征 的 节点 上 运行 指定 的 Pod 对 和 象 。 


DaemonSet 十 一 种 特殊 的 控制 茵 ， 它 有 特定 的 应 用 场景 ， 通 第 运 
行 那些 执行 系统 级 操作 任务 的 应 用 ， 其 应 用 场景 具体 如 下 。 


:运行 集群 存储 的 守护 进程 ， 如 在 各 个 节点 上 运行 glusterd 或 ceph 。 
:在 各 个 六 点 上 运行 日 志 收 集 守 护 进程 ， 如 fluentd 和 logstash 。 


:在 各 个 节点 上 运行 监控 系统 的 代理 守护 进程 ， 如 Prometheus Node 
Exporter ~ collectd ~、 Datadog agent 、 New Relic agent 或 Ganglia gmond 
稚 。 

二 


当然 ， 既 然 是 需要 运行 于 集群 内 的 每 个 节点 或 部 分 节点 ， 于 是 很 
多 场景 中 也 可 以 把 应 用 直接 运行 为 工作 节点 上 的 系统 级 守护 进程 ， 不 
过 ， 这 样 一 来 束 失 去 了 运用 Kubemetes 管 理 所 和 之 来 的 便捷 性 。 另 外 ， 
也 只 有 必须 将 Pod 对 象 运行 于 固定 的 儿 个 节点 并 且 需 要 先 于 其 他 Pod 启 
J 才 有 必要 使 用 DaemonSet 探 制 右 ， 否 则 残 应 该 使 用 Deployment 
至 制 右 。 


5.4.1 创建 DaemonSet 资 源 对 和 象 


DaemonSet 控 制 右 的 spec 字 段 中 般 套 使 用 的 字段 同样 主要 包 了 前 面 
讲 到 的 Pod 控 制 絮 资源 支持 的 selector、template 和 minReadySeconds， 
并 且 功 能 和 用 法 基本 相同 ， 但 它 不 支持 使 用 replicas， 毕 竟 DaemonSet 
并 不 是 基于 期 望 鸭 副本 数 来 控制 Pod 资 源 数量 ， 而 是 基于 节点 数量 ， 
但 template 是 必 选 字段 。 


下 面 的 资源 清单 文件 (filebeat-ds.yaml) 示例 中 定义 了 一 个 名 为 
filebeat-ds 的 DaemonSet 控 制 姻 ， 它 将 在 每 个 市 点 上 运行 一 个 和 ebeat 进 
程 以 收集 容器 相关 的 日 志 数 据 : 


apiVersion: appSs/VI 
kind: DaemonSet 
metadata: 
name: filebeat-ds 
Jabels: 
app: filebeat 
spec: 
selector: 
matchLabels: 
app: filebeat 
template: 
metadata: 

Jabels: 
app: filebeat 

name: filebeat 

spec: 

containers: 

- name: filebeat 
image: ikubernetes/filebeat:5.6.5-alpine 
env: 

- name: REDIS_ HOST 

value: db.ilinux.io:6379 
- Name: LOG_LEVEL 

value: info 


0 建 DaemonSet 资 源 的 命令 与 其 他 资源 的 创建 并 无 


~]$ kubectl1 apply -f filebeat-ds.yaml 
daemonset.apps "filebeat-ds" created 


局 注意 ”和 目 Kubernetes 1.8 版 本 起 ，DaemonSet 也 必须 使 用 


selector 来 匹配 Pod 模 板 中 指定 的 标签 ， 而 且 它 也 支持 matchLabels 和 
matchExpressions 两 种 标签 选择 器 。 


与 其 他 资源 对 象 相 同 ， 用 户 也 可 以 使 用 “kubectl describe” 命 令 查 看 
DaemonSet 对 象 的 详细 信息 。 下 面 命 令 的 结果 信息 中 ，Node-Selector 字 
段 的 值 为 空 ， 表 示 它 需要 运行 于 集群 中 的 每 个 节点 之 上。 而 当前 集群 
的 节点 数量 为 9， 因此 ， 其 期 望 的 Pod 副 本 数 (Desired Number of 
Nodes Scheduled) 为 3， 而 当前 也 已 经 成 功 创建 了 3 个 相关 的 Pod 对 象 


~]$ kubectl1 describe daemonsets filebeat-ds 

Name : filebeat-ds 

Selector: app=filebeat 

Node-Selector: <none> 

Desired Number of Nodes Scheduled: 3 

Current Number of Nodes Scheduled: 3 

Number of Nodes Scheduled with Up-to-date Pods: 3 

Number of Nodes Scheduled with Available Pods: 3 

Number of Nodes Misscheduled: 0 

Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed 


根据 DaemonSet 资 源 本 身 的 意义 ， 人 ebeat-ds 控 制 器 成 功 创建 的 3 个 
Pod 对 象 应 该 分 别 运 行 于 集群 中 的 每 个 节点 之 上 ， 这 一 点 可 以 通过 如 
下 命令 进行 验证 : 


~]$ kubectl1 get pods -1 app=filebeat \ 

-0 CusStom-columns=NAME:metadata.name, NODE: spec.nodeName 
NAME NODE 

filebeat-ds-sjrvb node01.ilinux.io 

filebeat-ds-swd47 node03.ilinux.io 

filebeat-ds-z7r97 node02.ilinux.io 


集群 中 的 部 分 工作 届 点 侦 尔 也 存在 需要 将 Pod 对 象 以 单一 实例 形 
式 运 行 的 情况 ， A 可 能 会 需要 为 其 
运行 特定 的 监控 代理 (agent) 程序 ， 等 等 。 其 实现 方式 与 前 面 讲 到 的 
Pod 资 源 的 节点 绑 定 机 制 类 似 ， 只 需要 在 pod 模板 的 spec 字 段 中 柑 套 使 
用 nodeSelector 字 段 ， 并 确保 其 值 定义 的 标签 选择 屁 与 部 分 特定 工作 市 
点 的 标签 匹配 即 可 。 


5.4.2 ”更 狐 DaemonSet 对 和 象 


DaemonSet 目 Kubernetes 1.6 版 本 起 也 开始 支持 更 新 机 市， 相关 配 
置 趾 义 在 spec.update-Strategy 藤 套 字 段 中 。 目 前 ， 它 文 持 RollingUpdate 
(滚动 更 新 ) 和 OnDelete (删除 时 更 新 ， 两 种 更 新 策略 ， 深 动 更 新 为 
默认 的 更 新 策略 ， 工 作 人 逻辑 类 似 于 Deployment 控 制 ， 不 过 仪 支持 使 用 
maxUnavailabe 属 性 定义 最 大 不 可 用 Pod 资 源 副 本 数 (默认 值 为 1)y) ， 而 
> 的 Pod 资 源 后 重建 并 更 狐 为 新 


例如 ， 将 此 前 创建 的 身 ebeat-ds 中 Pod 模 板 中 的 容器 镜像 升级 
为 “ikubernetes/filebeat: 5.6.6-alpine”， 使 用 “kubectl set image” 命 令 即 可 
实现 : 


~]$ kubectl1 set image daemonsets filebeat-ds filebeat=ikubernetes/filebeat:5.6.6- 
alpine 
daemonset.apps "filebeat-ds" image updated 


由 下 面 命 令 的 返回 结果 可 以 看 出 ，filebeat-ds 控 制 妖 Pod 模板 中 的 
容器 镜像 文件 已 经 完成 更 新 ， 对 深 动 更 新 策略 来 说 ， 它 会 自动 触发 更 
新 操作 。 用 户 也 可 以 通过 filebeat-ds 控 制 器 的 详细 信息 中 的 Events 字 上 段 
等 来 了 解 滚动 更 狐 的 操作 过 程 。 由 下 面 的 命令 结果 可 以 看 出 ， 默 认 的 
滚动 更 新 全 略 是 一 次 删除 一 个 工作 和 点 上 的 Pod 资 源 ， 竺 其 新 版 本 Pod 
资源 重建 完成 后 再 开始 操作 另 一 个 工作 和 点 上 的 Pod 资 源 : 


~]$ kubect1l describe daemonsets filebeat-ds 


Events: 

Type Reason Age From Message 

Normal SuccessfulDelete 3m daemonset-controller Deleted pod: filebeat- 
ds-swd47 

Normal SuccessfulCreate 3m daemonset-controller Created pod: filebeat- 
ds-pnhvl 

Normal SuccessfulDelete 3m daemonset-controller Deleted pod: filebeat- 
ds-z7r97 

Normal SuccessfulCreate 2m daemonset-controller Created pod: filebeat- 
ds-z2wdv 

Normal SuccessfulDelete 2m daemonset-controller Deleted pod: filebeat- 


ds-sjrvb 


Normal SuccessfulCreate 2m daemonset-controller Created pod: filebeat- 
ds-6pvdb 


DaemonSet 控 制 右 的 滚动 更 新 机 制 也 可 以 借助 于 minReadySeconds 
字段 控制 滚动 节 芝 ， 必 要 时 可 以 执行 暂停 和 继续 操作 ， 因 此 它 也 能 够 
设计 为 金 丝 雀 发 布 机 制 。 另 外 ， 故 障 的 更 新 操作 也 可 以 进行 回 滚 ， 包 
括 回 滚 至 revision 历 史记 录 中 的 任何 一 个 指定 的 版 本 。 鉴 于 篇 幅 ， 这 里 
不 再 给 出 其 详细 过 程 ， 感 兴趣 的 读者 可 参考 Deployment 控 制 器 的 步骤 
测试 其 实现 。 


5.5 Job 控制 器 


与 Deployment 及 DaemonSet 控 制 絮 管理 的 守护 进程 类 的 服务 应 用 不 
同 的 是 ，Job 控 制 絮 用 于 调配 Pod 对 象 运行 一 次 性 任务 ， 容 器 中 的 进程 
在 正常 运行 结束 后 不 会 对 其 进行 重启 ， 而 是 将 Pod 对 象 置 
于 “Completed”( 完 成 ) 状态 。 若 容器 中 的 进程 因 错 误 而 终止 ， 则 需要 
依 配 置 确定 重启 与 否 ， 未 运行 完成 的 Pod 对 象 因 其 所 在 的 节点 故障 而 意 
外 终止 后 会 被 重新 调度 。Job 控 制 器 的 Pod 对 象 的 状态 转换 如 图 5-13 所 
不 。 


Pod(exit 0) Completed 


Pod(exit !0) 
| restartPolicy:Never 


Failure 


it ! 
Bod 人 Pod(exit 0) Completed 
restartPolicy:OnFailure 


Failure.Restart 


图 5-13 ”Job 管理 下 Pod 资 源 的 运行 方式 


实践 中 ， 有 的 作业 任务 可 能 需要 运行 不 止 一 次 ， 用 户 可 以 配置 它 
们 以 串 行 或 并 行 的 方式 运行 。 总 结 起 来 ， 这 种 类 型 的 Job 挥 制 器 对 象 有 
两 种 ， 具 体 如 下 。 


单 工 作 队 列 (work queue) 的 串 行 式 Job: 即 以 多 个 一 次 性 的 作业 
方式 串 行 执行 多 次 作业 ， 直 至 满足 期 望 的 次 数 ， 如 图 5-14 所 示 ; 这 次 
ee a 在 某 个 时 刻 仅 存在 一 个 
Pod 资 源 天 8 


Job Controller ! 


\ 


图 5-14 ”上 串 行 式 多 任务 


-多 工作 队列 的 并 行 式 Job: 这 种 方式 可 以 设置 工作 队列 数 ， 即 作业 
数 ， 每 个 队列 仅 负责 运行 一 个 作业 ， 如 图 5-15a 所 示 ; 也 可 以 用 有 限 的 
工作 队列 运行 较 多 的 作业 ， 即 工作 队列 数 少 于 总 作业 数 ， 相 当 于 运行 
工作 队列 数 即 为 同时 可 运行 的 
Pod 资 源 : 3 


晤 
:| PodAl | PodA2 
- 
| PodB1 | PodB2 | PodB3 


图 5-15 ”多 队列 并 行 式 多 任务 


Job 控 制 器 第 用 于 管理 那些 运行 一 段 时 间 便 可 “完成 ”的 任务 ， 例 如 
计算 或 备份 操作 。 


5.5.1 创建 Job 对 和 象 


Job 控 制 嚣 的 spec 字 段 内 嵌 的 必要 字段 仪 为 template， 它 的 使 用 方 
式 与 Deployment 等 控制 器 并 无 不 同 。Job 会 为 其 Pod 对 象 自动 添加 “job- 
name=JOB _NAME” 和 “controller- uid=UID” 标 签 ， 并 使 用 标签 选择 需 完 
成 对 controller-uid 标 签 的 关联。 需要 注意 的 是 ，Job 位 于 API 群 
组 “batch/v1” 之 a 下 面 的 资源 清单 文件 (job-example.yaml) 中 定义 
了 一 个 Job 控 制 器 


apiVersion: batch/vi 
kind: Job 
metadata: 
name: job-example 
spec: 
template: 
spec: 
containers: 
- name: myjob 
image: alpine 
command: ["/bin/sh", "-c", "sleep 120"] 
restartPolicy: Never 


© 注意 “Pod 模 板 中 的 spec.restartPolicy 默 认为 “Always”， 这 对 
Job 控 制 器 来 说 并 不 适用 ， 因 此 必须 在 Pod 模 板 中 显 式 设 定 restartPolicy 
属性 的 值 为 “Never”* 或 “OnFailure”。 


使 用 “kubectl create” 或 “kubectl apply”* 命 令 完 成 创建 后 即 可 查看 相 
天 的 任务 状态 ，DESIRED 字 上 段 表 示 期 望 并 行 运行 的 Pod 资 源 数 量 ， 而 
SUCCESSFUL 则 表示 成 功 完成 的 Job 数 : 


~]$ kubect1 get jobs job-example 
NAME DESIRED SUCCESSFUL AGE 
job-example 1 0 7S 


相关 的 Pod 资 源 能 够 以 Job 控 制 器 名 称 为 标签 进行 匹配 : 


~]$ kubectl1 get pods -1 job-name=job-example 
NAME READY STATUS RESTARTS AGE 
job-example-6c5g8 1/1 Running 0 20s 


其 详细 信息 中 可 显示 所 使 用 的 标签 选择 大 及 匹配 的 Pod 资 源 的 标 
签 ， 具 体 如 下 : 


~]$ kubect1 describe jobs job-example 


Name : job-example 

Namespace: default 

Selector: controller-uid=48ae496f-1e81-11e8-9267-000c29abof5b 

Labels: controller-uid=48ae496f-1e81-11e8-9267-000c29abof5b 
job-name=job-example 

Annotations: <none> 

Parallelism: 1 

Completions: 1 


两 分 钟 后 ， 待 sleep 命 令 执行 完成 并 成 功 退 出 后 ，Pod 资 源 即 转换 
为 Completed 状 态 ， 并 且 不 会 再 于 “kubectl get pods” 命 令 中 出 现 ， 除 非 
为 其 使 用 选项 <--show-all” 或 简单 格式 的 “-a>: 


~]$ kubectl1 get pods -1 job-name=job-example -a 
NAME READY STATUS RESTARTS AGE 
job-example-6c5g8 0/1 Completed 0 3m 


此 上 时， 如果 使 用 “kubectl get jobs” 显 示 job-example 的 相关 信息 ， 那 
么 其 SUCCESSFUL 字 段 的 数字 就 不 再 为 “0”。 


5.5.2 ”并 行 式 Job 


将 并 行 度 属 性 .spec.parallelism 的 值 设置 为 1， 并 设置 总 任务 | 
数 .spec.completion 属 性 便 能 够 让 Job 探 制 器 以 串 行 方式 运行 多 任务 。 下 
面 是 一 个 串 行 运行 5 次 任务 的 Job 控 制 器 示例 : 


apiVersion: batch/vi 
kind: Job 
metadata: 
name: job-multi 
spec: 
completions: 5 
template: 
spec: 
containers: 
- name: myjob 
image: alpine 
command: ["/bin/sh", "-c", "sleep 20"] 
restartPolicy: OnFailure 


在 创建 之 后 或 者 创建 之 前 ， 可 以 于 男 一 终端 启动 Pod 资 源 的 列 出 


命令 “kubectl get pods-l job-name=job-multi--watch” 来 监控 其 变动 ， 以 了 
解 其 执行 过 程 。 


.spec.parallelism 能 够 定义 作业 执行 的 并 行 度 ， 将 其 设置 为 2 或 者 以 
上 的 值 即 可 实现 并 行 多 队列 作业 运行 。 同 时 ， 如 果 .spec.completions 使 
用 的 是 默认 值 1， 则 表示 并 行 度 即 作 业 总 数 ， 如 图 5-15a 所 示 ; 而 如 果 
将 .spec.completions 属 性 值 设置 为 大 于 .spec.parallelism 的 属性 值 ， 则 表 
示 使 用 多 队列 串 行 任务 作业 模式 ， 如 图 5-15b 所 示 。 例 如 ， 某 Job 探 制 
器 配置 中 的 spec 字 段 仍 套 了 如 下 属性 ， 表 示 以 2 个 队列 并 行 的 方式 ， 总 
共 运 行 5 次 的 作业 : 


spec: 
completions: 5 
parallelism: 2 


5.5.3 Job 扩容 


Job 控 制 颖 的 .spec.parallelism 定 义 的 并 行 度 表示 同时 运行 的 Pod 对 
象 数 ， 此 属 性 什 文 持 运 行 时 调 整 从 而 改变 其 队列 总 数 ， 实 现 扩 容 和 缩 
容 。 使 用 WU 命令 与 此 前 的 Deployment 对 象 相同 ， 即 “kubectl] scale-- 
replicas” 命 令 ， 例 如 在 其 运行 过 程 中 (未 完成 之 前 将 job-multi 的 并 行 
度 扩展 为 两 路 : 


~]$ kubectl1 scale jobs job-multi --replicas=2 
job.apps "job-multi" scaled 


dL 了 命令 后 可 以 看 到 ， 其 同时 运行 的 Pod 对 象 副 本 数量 立即 扩展 
| 


~]$ kubectl1 get pods -1 job-name=job-multi 


NAME READY STATUS RESTARTS AGE 
job-multi-c26rh 0/1 ContainerCreating 0 2s 
job-multi-tfj9k 1/1 Running 0 26s 


根据 工作 市 到 发 其 次 源 可 用 量 ， 适度 提高 Job 的 并 行 度 ， 能 够 大 大 
提升 其 完成 效率 ， 缩 短 运行 时 间 。 


5.5.4 删除 Job 


Job 探 制 右 竺 其 Pod 资 源 运 行 完 成 后 ， 将 不 再 占用 系统 资源 。 用 户 
可 按 需 保留 或 使 用 资源 删除 命令 将 其 删除 。 不 过 ， 如 果 某 Job 探 制 右 的 
容器 应 用 总 是 无 法 正常 结束 运行 ， 而 其 restartPolicy 叉 定 为 了 重启 ， 则 
它 可 能 会 一 直 处 于 不 停 地 重启 和 错误 的 循环 当中 。 所 幸 的 是 ，Job 控 制 
局 提供 了 两 个 属性 用 于 抑制 这 种 情况 的 发 生 ， 具 体 如 下 。 


.spec.activeDeadlineSeconds<integer> : Job 的 deadline， 用 于 为 其 
指定 最 大 活动 时 间 长 度 ， 超 出 此 时 长 的 作业 将 被 终止 。 


.spec.backoffLimit<integer> : 将 作业 标记 为 失败 状态 之 前 的 重 试 
次 数 ， 默 认 值 为 6。 


例如 ， 下 面 的 配置 片断 表示 其 失败 重 试 的 次 数 为 5， 并 且 如 果 超 出 
100 秒 的 时 间 仍 未 运行 完成 ， 那 么 其 将 被 终止 ， 


spec: 
backoffLimit: 5 
activeDeadlineSeconds: 100 


5.6 ”CronJob 探 制 覆 


CronJob 挥 制 絮 用 于 管理 Job 控 制 絮 资源 的 运行 时 间 。Job 控 制 器 定 
义 的 作业 任务 在 其 控制 占 资 源 创 建 之 后 便 会 立即 执行 ,但 CronJob 可 以 
以 类 似 于 Linux 操 作 系 统 的 周期 性 任务 作业 计划 (crontab) 的 方式 控制 
其 运行 的 时 间 点 及 重复 运行 的 方式 ， 具 体 如 下 。 


-在 未 来 某 时 间 点 运行 作业 一 次 。 
在 指定 的 时 间 点 重复 运行 作业 。 
CronJob 对 象 文 持 使 用 的 时 间 格 式 类 似 于 Crontab， 略 有 不 同 的 


征 ，CronJob 欣 制 硕 在 指定 的 时 间 点 时 ，“ 和 "的 意义 相同 ， 都 表示 
任何 可 用 的 有 效 值 。 


5.6.1 ”创建 CronJob 对 和 象 


CronJob 控 制 絮 的 spec 字 段 可 骨 套 使 用 以 下 字段 。 


jobTemplate<Object>: Job 控 制 右 模板 ， 用 于 为 CronJob 控 制 颖 生 
成 Job 对 象 ， 必 选 字段 。 


.Schedule<string>: Cron 格 式 的 作业 调度 运行 时 间 点 ; 必 选 字段 。 


:concurrencyPolicy<string>: 并 发 执行 策 略 ， 可 用 值 
有 “Allow” (允许) 、“Forbid”( 禁 止 ) 和 “Replace”(〈 替 换 ) ， 用 于 定 
义 前 一 次 作业 运行 尚未 完成 时 是 否 以 及 如 何 运 行 后 一 次 的 作业 。 


failedJobHistoryLimit<integer>: 为 失败 的 任务 执行 保留 的 历史 记 
了 永 数 ， 默 认为 1。 


“successfulJobsHistoryLimit<integer>: 为 成 功 的 任务 执行 保留 的 历 
史记 录 效 ， 默 认为 3。 


startingDeadlineSeconds<integer>: 因 各 种 原因 缺乏 执行 作业 的 时 
间 点 所 导致 的 启动 作业 错误 的 超时 时 长 ， 会 被 记 入 错误 历史 记录 。 


”suspend<boolean>: 是 否 挂 起 后 续 的 任务 执行 ， 默 认为 false， 对 
运行 中 的 作业 不 会 产生 影响 。 


下 面 是 一 个 定义 在 资源 清单 文件 (cronjob-example.yaml) 中 的 
CronJob 资 源 对 象 示 例 ， 它 每 隔 2 分 钟 运行 一 次 由 jobTemplate 定 义 的 简 
单 任务 : 


apiVersion: batch/vibetai 
kind: CronJob 
metadata: 
name: cronjob-example 
labels: 
app: mycronjob 
spec: 
schedule: ™*/2 * * * *" 
jobTemplate: 
metadata: 
labels: 


app: mycronjob-jobs 
spec: 
parallelism: 2 
template: 
spec: 
containers: 
- name: myjob 
image: alpine 
command: 
- /bin/sh 
- -C 
- date; echo Hello from the Kubernetes cluster; sleep 10 
restartPolicy: OnFailure 


运行 资源 创建 命 0 务 源 对 象 ， 而 后 再 通过 资 源 对 
象 的 相关 信息 了 解 运行 状态 。 下 面 命令 结果 中 的 SCHEDULE 是 指 其 调 
度 时 间 点 ，SUSPEND 表 示 后 纪 大 任务 是 天 处 于 挂 过 状态 即 暂停 任务 的 
调度 和 运行 ，ACTIVE 表 示 活 动 状态 的 Job 对 象 的 数量 ， 而 LAST 
SCHEDULE 则 表示 上 次 调度 运行 至 此 刻 的 时 长 : 


~]$ kubectl1 get cronjobs cronjob-example 
NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE 
cronjob-example /2 和 False 1 37S 1m 


名 提示 。 目 Kubernetes 1.8 起 ，CronJob 资 源 所 在 的 API 资 源 组 
从 batch/v2alphal 移 至 batch/vlbetal 中 ， 并 且 查 看 其 资源 格式 时 也 要 使 
用 --api-version 选 项 指定 其 所 在 的 货源 组 ， 即 “kubectl explain cronjob-- 
api-version='batch/vlbetal’” ° 


5.6.2 ”CronJob 的 控制 机 制 


CronJob 控 制 絮 是 一 个 更 高 级 别 的 资源 ， 它 以 Job 控 制 妖 资源 为 其 
管控 对 象 ， 并 借助 它 管理 Pod 资 源 对 象 。 因 此 ， 要 使 用 类 似 如 下 命令 
来 查看 某 CronJob 控 制 右 创建 的 Job 资 源 对 象 ， 其 中 的 标签 “mycronjob- 
jobs” 是 在 创建 cronjob-example 时 为 其 指定 。 不 过 ， 只 有 相关 的 Job 对 和 象 
被 调度 执行 时 ， 此 命令 才能 将 其 正常 列 出 。 可 列 出 的 Job 对 象 的 数量 取 
决 于 CronJob 资 源 的 .spec.successfulJobsHistoryLimit 的 属性 值 ， 默 认为 
3 Oo 


~]$ kubect1 get jobs -1 app=mycronjob-jobs 


NAME DESIRED SUCCESSFUL AGE 
cronjob-example-1520057880 <none> 2 5m 
cronjob-example-1520058000 <none> 2 3m 
cronjob-example-1520058120 <none> 2 1m 


如 果 作业 重复 执行 时 指定 的 时 间 点 较 近 ， 而 作业 执行 时 长 (普遍 
或 偶尔 ) 路过 了 其 两 次 执行 的 时 间 长 度 ， 则 会 出 现 两 个 Job 对 象 同 时 存 
在 的 情形 。 有 些 Job 对 象 可 能 会 存在 无 法 或 不 能 同时 运行 的 情况 ， 这 个 
时 候 就 要 通过 .spec.concurrencyPolicy 属 性 控制 作业 并 存 的 机 制 ， 其 默 
认 值 为 “<Allow”， 即 允许 前 后 Job， 甚 至 属于 同一 个 CronJob 的 更 多 Job 
同时 运行 。 其 他 两 个 可 用 值 中 , “Forbid” 用 于 禁止 前 后 两 个 Job 同 时 运 
行 ， 如 有 果 前 一 个 尚未 结束 ， 后 一 个 则 不 予 启动 ( 跳 过 ) ，“Replace” 用 
于 让 后 一 个 Job 取 代 前 一 个 ， 即 终止 前 一 个 并 局 动 后 一 个 。 


5.7 ReplicationController 


ReplicationController (简称 rc 或 RC) 是 Kubernetes 较 早 实现 的 Pod 
控制 右 ， 用 于 确保 Pod 资 源 的 不 间断 运行 。 不 过 ，Kubernetes 后 来 设计 
了 ReplicaSet 及 其 更 高 一 级 的 控制 右 Deployment 来 取 
ReplicationController， 并 表示 在 后 来 的 版 本 中 可 能 会 上 废弃 RC。 因 此 ， 
这 里 不 再 对 ReplicationController 做 过 多 的 介绍 。 事 实 上 ， 它 的 使 用 方 
式 与 ReplicaSet 相 同 ， 一 旦 用 到 时 ， 绝 大 多 数 操作 都 可 以 迁移 使 用 ， 感 
兴趣 的 读者 可 以 目 行 测试 。 


5.8 Pod 中 上 断 预 算 


尽管 Deployment 或 ReplicaSet 一 类 的 控制 器 能 够 确保 相应 Pod 对 象 
的 副本 数量 不 断交 近期 望 的 数量 ， 但 它 却 无 法 保证 在 某 一 时 刻 一 定 会 
存在 指定 数量 或 比例 的 Pod 对 象 ， 然 而 这 种 需求 在 某 些 强 调 服 务 可 用 
性 的 场景 中 却 是 必 备 的 。 于 是 ，Kubernetes 目 1.4 版 本 起 开始 引入 Pod 中 
汤 预 算 \PodDisruptionBudget， 简 称 PDB) 类 型 的 资源 ， 用 于 为 那些 
目 愿 的 (Voluntary) 中 断 做 好 预算 方案 (Budget) ， 限 制 可 目 愿 中 晰 
ee 的 Pod 副 本 数 ， 以 确保 服务 的 高 可 用 


Pod 对 象 会 一 直 存 在 ， 除 非 有 意 将 其 销 驱 ， 或 者 出 现 了 不 可 避免 
的 硬件 或 系统 软件 错误 。 非 目 愿 中 断 是 指 那些 由 不 可 控 外 界 因 素 导 致 
的 Pod 中 断 退 出 操作 ， 例 如 ， 硬 件 或 系统 内 核 改 障 、 网 络 故 障 以 及 区 
点 货源 不 足 导 致 Pod 对 象 被 驱逐 等 ;而 那些 由 用 户 特地 执行 的 管理 操 
作 导 致 的 Pod 中 断 则 称 为 " 目 愿 中 断 ”， 例 如 排 空 万 点 、 人 为 删除 Pod 对 
象 、 由 更 新 操作 触发 的 Pod 对 象 重建 等 。 部 车 在 Kubernetes 的 每 个 应 用 
程序 都 可 以 创建 一 个 对 应 的 PDB 对 象 以 限制 目 原 中断 时 最 大 可 以 中 断 
0 的 副本 数 ， 从 而 保证 应 用 目 身 的 高 可 


PDB 资 源 可 以 用 来 保护 由 控制 器 管理 的 应 用 ， 此 时 几乎 必然 意味 
着 PDB 使 用 等 同 于 相关 控制 锅 对 象 的 标签 选择 锅 以 精确 关联 至 目标 Pod 
对 象 ， 文 持 的 控制 右 类 型 包括 Deployment、ReplicaSet 和 StatefulSet 
等 。 同 时 ，PDB 对 象 也 可 以 用 来 保护 那些 纯粹 是 由 定制 的 标签 选择 右 
目 由 选择 的 Pod 对 象 。 


定义 PDB 资源 时 ， 其 spec 字 段 主 要 租 套 使 用 以 下 三 个 字段 。 


-selector<Object>: 当前 PDB 对 象 使 用 的 标签 选择 器 ， 一 般 是 与 相 
天 的 Pod 控 制 絮 使 用 同一 个 选择 侣 。 


:minAvailable<string>: Pod 自 愿 中 汤 的 场景 中 ， 至 少 要 保证 可 用 
i 比例 ， 要 阻止 任何 Pod 对 象 发 生 目 愿 中 断 ， 可 将 其 设 
为 10096。 


-maxUnavailable<string>: Pod 目 愿 中 断 的 场景 中 ， 最 多 可 转换 为 
不 可 用 状态 的 Pod 对 象 数量 或 比例 ，0 值 意味 着 不 允许 Pod 对 象 进行 目 
愿 中 断 ; 此 字段 与 minAvailable 互 不 。 


下 面 的 示例 定义 了 一 个 PDB 对 象 ， 它 对 5.3.1 太 中 由 Deployment 控 
制 硕 myapp-deploy 创 建 的 Pod 对 象 设 置 了 Pod 中 断 预 算 ， 要 求 其 最 少 可 
用 的 Pod 对 象 数量 为 2 个 : 


apiVersion: policy/vibetali 
kind: PodDisruptionBudget 
metadata: 
name: myapp-pdb 
spec: 
minAvailable: 2 
selector: 
matchLabels: 
app: myapp 


PDB 人 资源 对 象 创建 完成 后 ， 在 它 的 简要 信息 输出 中 也 标明 了 最 少 
可 用 的 Pod 对 象 个 数 ， 以 及 允许 中 断 的 Pod 对 象 个 数 : 


~]$ kubectl1 get pdb 
NAME MIN AVAILABLE MAX UNAVAILABLE ALLOWED DISRUPTIONS AGE 
myapp-pdb 2 N/A 1 24S 


接 下 来 可 通过 命令 手动 删除 myapp-deploy 控 制 器 下 的 所 有 Pod 对 象 
2 1 并 监控 各 Pod 对 象 被 终止 的 过 程 来 验证 PDB 资源 对 
控制 功效 。 


5.9 本章 小 结 


本 瘟 主 要 讲解 了 Kubernetes 的 Pod 控 制 器 ， 它们 是 “工作 人 负载 "类 资 
源 的 核心 组 成 部 分 ， 是 基于 Kubernetes 运 行 应 用 的 最 重要 的 资源 类 型 
之 一， 具体 如 下 = 


工作 负载 类 型 的 控制 硕 根 据 业 务 需求 管控 Pod 资 源 的 生命 周期 。 


.ReplicaSet 可 以 确保 守护 进程 型 的 Pod 资 源 始终 具有 精确 的 、 处 于 
运行 状态 的 副本 数量 ， 并 支持 Pod 规 模 的 伸缩 机 制 ， 它 是 新 一 代 的 
ReplicationController 控 制 姻 ， 不 过 用 户 通常 不 应 该 直接 使 用 
ReplicaSet， 而 是 要 使 用 Deployment 。 


.Deployment 是 建构 在 ReplicaSet 上 的 更 加 抽象 的 工作 负载 型 控制 
锅 ， 文 持 多 种 更 新 策略 及 发 布 机 制 。 


-Job 控制 絮 能 够 控制 相应 的 作业 任务 得 以 正常 完成 并 退出 ， 支 持 
并 行 式 多 任务 。 

-CronJob 控 制 器 用 于 控制 周期 性 作业 任务 ， 其 功能 类 似 于 Linux 探 
作 系 统 上 的 Crontab。 


:PodDisruptionBudget 资 源 对 象 为 Kubernetes 系 统 上 的 容 妮 化 应 用 提 
供 了 高 可 用 能 力 。 


第 6 章 ”Service 和 Ingress 


运行 于 Pod 中 的 部 分 容器 化 应 用 是 回 客 户 端 提供 服务 的 守护 进 
程 ， 例 如 ，nginx、 tomcat 和 etcd 等 ， 它 们 受 探 于 控制 右 资 源 对 象 ， 存 
在 生命 周期 ， 在 自愿 或 非 自 愿 中 断后 只 能 被 重 构 的 新 Pod 对 象 所 取 
代 ， 属 于 非 可 再 生 类 的 组 件 。 于 是 ， 在 动态 、 弹 性 的 管理 模型 下 ， 
Service 资 源 用 于 为 此 类 Pod 对 象 提 供 一 个 固定 、 社 一 的 访问 接口 及 仙 
载 均衡 的 能 力 ， 并 支持 借助 于 新 一 代 DNS 系 统 的 服务 发 现 功 能 ， 解 决 
客户 端 发 现 并 访问 容器 化 应 用 的 难题 。 


然而 ，Service 及 Pod 对 象 的 IP 地 址 都 仪 在 Kubernetes 集 群 内 可 达 ， 
它们 无 法 接 入 集群 外 部 的 访问 流量 。 解决 此 类 问题 的 办 法 中 ， 除 了 在 
单一 节点 上 做 端口 暴露 (hostPort) 及 让 Pod 资 源 共享 使 用 工作 节点 的 
网 络 名 称 空间 (hostNetwork) 之 外 ， 更 推荐 用 户 使 用 的 是 NodePort 或 
LoadBalancer 类 型 的 Service 资 源 ， 或 者 是 有 着 七 层 负载 均衡 能 力 的 
Ingress 资 源 。 


6.1 Service 资 源 及 其 实现 模型 


Service 是 Kubernetes 的 核心 资源 类 型 之 一 ， 通 常 可 看 作 微服 务 的 
一 种 实现 。 事 实 上 它 是 一 种 抽象 : 通过 规则 定义 出 由 多 个 Pod 对 象 组 
合 而 成 的 逻辑 集合 ， 以 及 访问 这 组 Pod 的 策略 。Service 关 联 Pod 资 源 的 
规则 要 借助 于 标签 选择 器 来 完成 ， 这 一 点 类 似 于 第 5 章 讲 到 的 Pod 控 制 
五 总 


6.1.1 Service 资 源 概 壕 


由 Deployment 等 控制 器 管理 的 Pod 对 象 中 断后 会 由 新 建 的 资源 对 象 
所 取代 ， 而 扩 缩 容 后 的 应 用 则 会 带 来 Pod 对 象 群体 的 变动 ， 随 之 变化 的 
还 有 Pod 的 IP 地 址 访问 接口 等 ， 这 也 是 编排 系统 之 上 的 应 用 程序 必然 要 
面临 的 问题 。 例 如 ， 当 图 6-1 中 的 Nginx Pod 作 为 客户 端 访问 tomcat Pod 
中 的 应 用 时 ，IP 的 变动 或 应 用 规模 的 缩减 会 导致 客户 六 访问 错误 ， 而 
Pod 规 模 的 扩容 又 会 使 得 客户 端 无 法 有 效 地 使 用 新 增 的 Pod 对 象 ， 从 而 
影响 达成 规模 扩展 之 目的 。 为 此 ，Kubernetes 特 地 设计 了 Service 资 源 来 
解决 此 类 问题 。 


kubernets cluster 


deploy-nginx 


deploy-tomcat 
让 


tomcat tomcat . tomcat 


Be oe ee 


图 6-1 ”Pod 及 其 客户 端 示例 


Service 资 源 基 于 标签 选择 器 将 一 组 Pod 定 义 成 一 个 逻辑 组 合 ， 并 通 
过 目 己 的 IP 地 址 和 端口 调度 代理 请 求 至 组 内 的 Pod 对 象 之 上 ， 如 图 6-2 所 
示 ， 它 向 客户 端 隐藏 了 真实 的 、 人 处 理 用 户 请 求 的 Pod 资 源 ， 使 得 客户 端 
的 请 求 看 上 去 就 像 是 由 Service 直 接 处 理 并 进行 响应 的 一 样 。 


Pod 


Pod role:backend 


role:backend 


role:backend | 


Service(ClusterIP:Port) 
label 
selector 
图 6-2 ”Kubernetes Service 资 源 模型 示意 图 


Service 对 和 象 的 IP 地 址 也 称 为 Cluster IP， 它 位 于 为 Kubernetes 集 群 配 
置 指定 专用 IP 地 址 的 范围 之 内 ， 而 且 是 一 种 虚拟 IP 地 址 ， 它 在 Service 对 
象 创建 后 即 保持 不 变 ， 并 且 能 够 被 同一 集群 中 的 Pod 资 源 所 访问 。 
Service 端 口 用 于 接收 客户 端 请 求 并 将 其 转发 至 其 后 端的 Pod 中 应 用 的 相 
应 端口 之 上， 因此， 这 种 代理 机 制 也 称 为 “端口 代理 ” (port proxy) 或 
四 层 代 理 ， 它 工作 于 TCP/IP 协 议 栈 的 传输 层 。 


通过 其 标签 选择 器 匹配 到 的 后 端 Pod 资 源 不 止 一 个 时 ，Service 资 源 
能 够 以 负载 均衡 的 方式 进行 流量 调度 ， 实 现 了 请 求 流量 的 分 发 机 制 。 
Service 与 Pod 对 象 之 间 的 关联 关系 通过 标签 选择 器 以 松 耦 合 的 方式 建 
立 ， 它 可 以 移 于 Pod 对 象 创建 而 不 会 发 生 错误 ， 于 是 ， 创 建 Service 与 
Pod 资 源 的 任务 可 由 不 同 的 用 户 分 别 完成 ， 人 例如， 服务 架构 的 设计 和 创 
建 由 运 维 工程 师 进 行 ， 而 填充 其 实现 的 Pod 资 源 的 任务 则 可 交 由 开发 者 
进行 。Service、 控 制 器 与 Pod 之 间 的 关系 如 图 6-3 所 示 。 


matchLables: 
role:backend 


kubernetes cluster ， 


nginx | | nginx | 
se | nginx-deploy 
Bg Service 
一 (tomcat-service) 》 一 
,> tomcat-deploy 
| 


图 6-3 ”Service、 控 制 髓 与 Pod 


Service 资 源 会 通过 API Server 持 续 监 视 着 (watch) 标签 选择 器 匹配 
到 的 后 端 Pod 对 象 ， 并 实时 跟踪 各 对 和 象 的 变动 ， 例 如 ， 了 PP 地址 变动 、 对 
象 增加 或 减少 等 。 不 过 ， 需 要 特别 说 明 的 是 ，Service 并 不 直接 链接 至 
Pod 对 象 ， 它 们 之 间 还 有 一 个 中 间 层 一 Endpoints 资 源 对 象 ， 它 是 一 个 由 
IP 地 址 和 端口 组 成 的 列表 ， 这 些 IP 地 址 和 端口 则 来 自 于 由 Service 的 标签 
od 。 这 也 是 很 多 场景 中 会 使 用 “Service 的 后 端 端 


点 ”(Endpoints) 这 一 术语 的 原因 。 默 认 情 况 下 ， 创 建 Service 资 源 对 象 
时 ， 其 关联 的 Endpoints 对 象 会 自动 创建 。 


6.1.2 ”虚拟 IP 和 服务 代理 


简单 来 讲 ， 一 个 Service 对 象 就 是 工作 节点 上 的 一 些 iptables 或 ipvs 规 
则 ， 用 于 将 到 达 Service 对 象 耻 地 址 的 流量 调度 转发 至 相应 的 Endpoints 
对 和 象 指 回 的 卫 地 址 和 端口 之 上 。 工 作 于 每 个 工作 记 点 的 kube-proxy 组 件 
通过 API Server 持 续 监 探 着 各 Service 及 与 其 天 联 的 Pod 对 象 ， 并 将 其 创 
建 或 变动 实时 反映 至 当前 工作 节点 上 相应 的 iptables 或 ipvs 规 则 上 。 窗 户 
端 、Service 及 其 Pod 对 象 的 关系 如 图 6-4 所 示 。 


名 提示 “Netfilter 是 Linux 内 核 中 用 于 管理 网 络 报 文 的 框 絮 ， 它 
具有 网 络 地 址 转换 (NAT) 、 报 文 改 动 和 报 文 过 滤 等 防火 墙 功 能 ， 用 
户 借助 于 用 户 空 间 的 iptables 等 工具 可 按 需 上 自由 定制 规则 使 用 其 各 项 功 
能 。ipvs 是 借助 于 Netfilter 实 现 的 网 络 请 求 报 文 调度 框架 ， 支 持 rr、 
wrr、lc、wlc、sh、sed 和 ng 等 十 余 种 调度 算法 ， 用 户 空间 的 命令 行 工具 
是 ipvsadm， 用 于 管理 工作 于 ipvs 之 上 的 调度 规则 。 


Service IP 事 实 上 是 用 于 生成 iptables 或 ipvs 规 则 时 使 用 的 IP 地 址 ， 它 
仅 用 于 实现 Kubernetes 集 群 网 络 的 内 部 通信 ， 并 且 仅 能 够 将 规则 中 定义 
的 转发 服务 的 请 求 作为 目标 地 址 予以 啊 应 ， 这 也 是 它 被 称 为 虚拟 IP 的 
原因 之 一 。kube-proxy 将 请 求 代理 至 相应 端点 的 方式 有 三 种 : userspace 

(用 户 空间 ) 、iptables 和 ipvs。 


1.userspace 代 理 模型 


此 处 的 userspace 是 指 Linux 操 作 系 统 的 用 户 空间 。 这 种 模型 中 ， 
kube-proxy 负 责 跟踪 API Server 上 Service 和 Endpoints 对 象 的 变动 (创建 
或 移 除 ) ， 并 据 此 调整 Service 资 源 的 定义 。 对 于 每 个 Service 对 象 ， 它 
会 随机 打开 一 个 本 地 端口 (运行 于 用 户 空间 的 kube-proxy 进 程 负 责 监 
听 ) ， 任 何 到 达 此 代理 端口 的 连接 请 求 都 将 被 代理 至 当前 Service 资 源 
后 端的 各 Pod 对 象 上 ， 至 于 会 挑 中 哪个 Pod 对 象 则 取决 于 当前 Service 资 
源 的 调度 方式 ， 默 认 的 调度 算法 是 轮 询 (round-robin) ， 其 工作 逻辑 如 
图 6-5 所 示 。 另 外 ， 此 类 的 Service 对 象 还 会 创建 iptables 规 则 以 捕获 任何 
到 达 ClusterIP 和 端口 的 流量 。 在 Kubernetes 1.1 版 本 之 前 ，userspace 是 默 
认 的 代理 模型 。 
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Service A Kubernetes Cluster | 
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图 6-4 kube-proxy 和 Service 


configure iptables 1 


! iptables kube-proxy 


图 6-5 ”userspace 代 理 模 型 


这 种 代理 模型 中 ， 请 求 流量 到 达 内 核 空间 后 经 由 套 接 字 送 往 用 户 
空间 的 kube-proxy， 而 后 再 由 它 送 回 内 核 空间 ， 并 调度 至 后 端 Pod。 这 
种 方式 中 ， 请 求 在 内 核 空间 和 用 户 空间 来 回转 发 必然 会 导致 效率 不 
高 。 
2.iptables 代 理 模 型 


同 前 一 种 代理 模型 类 似 ，iptables 代 理 模型 中 ，kube-proxy 负 贡 跟 踩 
API Server 上 Service 和 Endpoints 对 象 的 变动 (创建 或 移 除 ) ， 并 据 此 做 
出 Service 资 源 定义 的 变动 。 同 时 ， 对 于 每 个 Service， 它 都 会 创建 
iptables 规 则 直接 捕获 到 达 ClusterIP 和 Port 的 流量 ， 并 将 其 重 定 癌 至 当前 
Service 的 后 端 ， 如 图 6-6 所 示 。 对 于 每 个 Endpoints 对 象 ，Service 资 源 会 


为 其 创建 iptables 规 则 并 关联 至 挑选 的 后 端 Pod 资 源 ， 默 认 算 法 是 随机 调 
度 (random) 。iptables 代 理 模式 由 Kubernetes 1.1 版 本 3 引入， 并 自 1.2 版 
开始 成 为 默认 的 类 型 。 


在 创建 Service 资 源 时 ， 集 群 中 每 个 站 点 上 的 kube-proxy 都 会 收 到 通 
知 并 将 其 定义 为 当前 节点 上 的 iptables 规 则 ， 用 于 转发 工作 接口 接收 到 
的 与 此 Service 资 源 的 ClusterIP 和 端口 的 相关 流量 。 客 户 端 发 来 的 请 求 被 
相关 的 iptables 规 则 进行 调度 和 目标 地 址 转换 (DNAT) 后 再 转发 至 集群 
内 的 Pod 对 象 之 上 。 


相对 于 用 户 空间 模型 来 说 ，iptables 模 型 无 须 将 流量 在 用 户 空间 和 
内 核 空间 来 回 切换 ， 因 而 更 加 高 效 和 可 靠 。 不 过 ， 其 缺点 是 iptables 代 
理 模 型 不 会 在 被 挑 中 的 后 端 Pod 资 源 无 啊 应 时 目 动 进行 重 定 同 ， 而 
userspace 模 型 则 可 以 。 


3.ipvs 代 理 模型 


Kubernetes 目 1.9-alpha 版 本 起 引入 了 ipvs 代 理 模型 ， 晶 目 1.11 版 本 起 
成 为 默认 设置 。 此 种 模型 中 ，kube-proxy 跟 踪 API Server 上 Service 和 
Endpoints 对 象 的 变动 ， 据 此 来 调用 netlink 接 口 创 建 ipvs 规 则 ， 并 确保 与 
API Server 中 的 变动 保持 同步 ， 如 图 6-7 所 示 。 它 与 iptables 规 则 的 不 同 
之 处 仅 在 于 其 请 求 流量 的 调度 功能 由 ipvs 实 现 ， 余 下 的 其 他 功能 仍 由 
iptables 完 成 。 


kube-proxy 


confieure iptables 


图 6-6 ”iptables 代理 模型 


一 


kube-proxy 


configure ipvs 


图 6-7 ”ipvs 代 理 模 型 


类 似 于 iptables 模 型 ，ipvs 构 建 于 netfilter 的 钧 子 函 数 之 上 ， 但 它 使 
用 hash 表 作为 底层 数据 结构 并 工作 于 内 核 空间 ， 因 此 具有 流量 转发 速度 
快 、 规 则 同步 性 能 好 的 特性 。 另 外 ，ipvs 支 持 从 多 调度 算法 ， 例 如 Ir、 
lc、dh、sh、sed 和 nq 等 。 


6.2 Service 资 源 的 基础 应 用 


Service 资 呐 源 本 号 并 不 提供 任何 服务 ， 真正 处 理 并 啊 应 客户 ， 端 请 求 
的 是 后 端的 Pod 资 源 ， 这 些 Pod 资 源 通常 由 第 5 章 中 介绍 的 各 类 控制 需 
对 象 所 创建 和 管理 ， 因此 Service 资 源 通 弟 要 与 控制 器 资源 (最 为 常用 
J 协同 使 用 以 完成 应 用 的 创建 和 对 外 发 


6.2.1 创建 Service 资 源 


创建 Service 对 象 的 常用 方法 有 两 种 ， 一 是 直接 使 用 “kubectl 
expose” 命 令 ， 这 在 前 面 第 3 章 中 已 经 介绍 过 其 使 用 方式 ， 男 一 个 是 使 
用 资源 配置 文件 ， 它 与 此 前 使 用 资源 清单 文件 配置 其 他 资源 的 方法 类 
似 。 定 义 Service 资 源 对 象 时 ，spec 的 两 个 较为 常用 的 内 骸 字 段 分 别 为 
selector 和 ports， 分 别 用 于 定义 使 用 的 标签 选择 絮 和 要 欢 露 的 端口 。 下 
面 的 配置 清单 是 一 个 Service 资 源 示例 : 


kind: Service 
apiVersion: v1 
metadata: 
name: myapp-svc 
spec: 
selector: 
app: myapp 
ports: 
- protocol: TCP 
port: 80 
targetPort: 80 


Service 资 源 myapp-svc 通 过 标签 选择 絮 天 联 至 标签 
为 “app=myapp” 的 各 Pod 对 象 ， 它 会 自动 创建 名 为 myapp-svc 的 
Endpoints 资 源 对 象 ， 并 目 动 配置 一 个 ClusterIP， 暴 露 的 端口 由 port 字 段 
进行 指定 ， 后 端 各 Pod 对 象 的 端口 则 由 targetPort 给 出 ， 也 可 以 使 用 同 
port 字 段 的 默认 值 。myapp-svc 创 建 完 成 后 ， 使 用 下 面 的 命令 即 能 获取 
相关 的 信息 输出 以 了 解 资 源 的 状态 : 


~]$ kubect1 get Svc myapp-svc 
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE 
myapp-svc ClusterIP 10.107.208.93 <none> 80/TCP 56s 


上 面 命 令 中 的 结果 显示 ，myapp-svc 的 类 型 为 默认 的 ClusterIP， 其 
使 用 的 地 址 自动 配置 为 10.107.208.93。 此 类 型 的 Service 对 象 仅 能 通过 
此 IP 地 址 接受 来 自 于 集群 内 的 客户 端 Pod 中 的 请 求 。 若 集群 上 存在 标签 
为 “app=myapp” 的 Pod 资 源 ， 则 它们 会 被 关联 和 创建 ， 作 为 此 Service 对 
象 的 后 端 Endpoint 对 象 ， 并 负责 接收 相应 的 请 求 流 量 。 类 似 下 面 的 命 


令 可 用 于 获取 Endpoint 资 源 的 端点 列表 ， 其 相关 内 呈 是 由 第 5 章 中 的 
Deployment 控 制 妖 创 建 的 Pod 对 象 的 套 接 字 信息 言 轧 组 成 由 


~]$ kubect1 get endpoints myapp-svc 
NAME ENDPOINTS AGE 
myapp-svc 10.244.1.109:80,10.244.2.249:80,10.244.3.93:80 2m 


名 提示 “也 可 以 不 为 Service 资 源 指定 . selector 属 性 值 ， 其 
关联 的 Pod 资 源 可 由 用 户 手动 创建 Endpoints 资 源 进行 定义 。 


Service 对 象 创建 完成 后 即 可 作为 服务 被 各 客户 端 访问 ， 但 要 真正 
啊 应 这 些 请 求 ， 还 是 要 依赖 于 各 后 端的 资源 对 象 。 


6.2.2 ”向 Service 对 象 请 求 服 务 


Service 资 源 的 默认 类 型 为 ClusterIP， 它 仅 能 接收 来 自 于 集群 中 的 
Pod 对 象 中 的 客户 端 程序 的 访问 请 求 。 下 面 创 建 一 个 专用 的 Pod 对 和 象 ， 
利用 其 交互 式 接口 完成 访问 测试 。 为 了 简单 起 见 ， 这 里 选择 直接 创建 
一 个 临时 使 用 的 Pod 对 象 作为 交互 式 使 用 的 客户 端 进 行 ， 它 使 用 CirrOS 
镜像 ， 默 认 的 命令 提示 符 为 /#”: 


/A 
~]$ kubect1l run cirros-$RANDOM --rm -it --image=cirros -- sh 
/# 


名 提示 ”CirOS 是 设计 用 来 进行 云 计算 环境 测试 的 Linux 微 型 
发 行 版 ， 它 拥有 HTTP 客 户 端 工具 curl 等 。 


而 后 ， 在 容 恬 的 交互 式 接口 中 使 用 crul 命 令 对 myapp-svc 服 务 的 
ClusterIP (10.107.208.93) 和 Port (80/tcp) 发 起 访问 请 求 测试 : 


/# curl http://10.107.208.93:80/ 
Hello MyApp | Version: v1i | <a href="hostname.html">Pod Name</a> 


myapp 容 器 中 的 “/hostname.html* 页 面 能 够 输出 当前 容器 的 主机 
名 ， 可 反复 加 myapp-svc 的 此 URL 路 径 发 起 多 次 请 求 以 验证 其 调度 的 歼 
果 : 


/# for loop in 1 2 3 4; do curl http://10.107.208.93:80/hostname.html; done 
deploy-myapp-86b4b8c75d-rbhf1 
deploy-myapp-86b4b8c75d-mhbkd 
deploy-myapp-86b4b8c75d-xk8qb 


当前 Kubermnetes 集 群 的 Service 代 理 模 式 为 iptables， 它 默认 使 用 随 
机 调度 算法 ， 因 此 Service 会 将 客户 端 请 求 随 机 调度 至 与 其 关联 的 某 个 
后 。 命令 取样 次 数 越 大 ， 其 调度 效果 也 越 接近 于 算法 的 
目标 效果 。 


6.2.3 ”Service 会 话 粘 性 


Service 资 源 还 支持 Session affinity (粘性 会 话 或 会 话 粘性 ) 机 制 ， 
它 能 够 将 来 自 同 一 个 客户 端的 请 求 始终 转发 至 同一 个 后 端的 Pod 对 
象 ， 这 意味 着 它 会 影响 调度 算法 的 流量 分 发 功用 ， 进 而 降低 其 负载 均 
衡 的 效果 。 因 此 ， 当 客户 端 访问 Pod 中 的 应 用 程序 时 ， 如 果 有 基于 客 
户 端 身份 保存 某 些 私 有 信息 ， 并 基于 这 些 私 有 信息 追踪 用 户 的 活动 等 
一 类 的 需求 时 ， 那 么 应 该 启用 session affinity 机 制 。 


Session affinity 的 效 末 仅 会 在 一 定时 间 期 限 内 生效 ， 默 认 值 为 
10800 秒 ， 超 出 此 时 长 之 后 ， 客 户 端的 再 次 访问 会 被 调度 算法 重新 调 
度 。 男 外 ，Service 资 源 的 Session affinity 机 制 仅 能 基于 客户 端 卫 地 址 识 
别 客户 问 身 份 ， 它 会 把 经 由 同一 个 NAT 服 务 絮 进行 源 地 址 转换 的 所 有 
客户 端 识 别 为 同一 个 客户 端 ， 调 度 粒 度 粗 糙 且 效果 不 佳 ， 因 此 ， 实 践 
和 此 种 方法 实现 粘性 会 话 。 此 下 仅 用 于 为 读者 介绍 其 功 
能 及 实现 。 


Service 资 源 通 过 .spec.sessionAffinity 和 和 .spec.sessionAffinityConfig 两 
个 字段 配置 粘性 会 话 。spec.sessionAffinity 字 段 用 于 定义 要 使 用 的 粘性 
会 话 的 类 型 ， 它 仪 支持 使 用 “None” 和 “ClientIP” 两 种 属性 值 。 


.None: 不 使 用 sessionAffinity， 默 认 值 。 


'ClientIP: 基于 客户 端 卫 地 址 识别 客户 端 身 份 ， 把 来 目 同一 个 源 IP 
地 址 的 请 求 始终 调度 至 同一 个 Pod 对 象 。 


在 启用 粘性 会 话机 制 时 ，.spec.sessionAffinityConfig 用 于 配置 其 会 
话 保持 的 时 长 ， 它 是 一 个 磐 套 字段 ， 使 用 格式 如 下 所 示 ， 其 可 用 的 时 
长 范围 为 “1~86400”， 默 认为 10800 秒 : 


spec: 
sessionAffinity: ClientIP 
sessionAffinityConfig: 
clientIP: 
timeoutSeconds: <integer> 


例如 ， 基 于 默认 的 10800 秒 的 超时 时 长 ， 使 用 下 面 的 命令 修改 此 前 
的 myapp-svc 使 用 Session affinity 机 制 |: 


~]$ kubectl1 patch services myapp-svc -p '{"spec": {"sessionAffinity": 
"ClientIP"}}' 
service "myapp-svc" patched 


训 后 得 次 于 交互 式 客户 六 内 测试 其 访问 效果 即 可 验证 其 会 放 术 性 
效果 。 


/# for loop in 1 2 3 4; do curl http://10.107.208.93:80/hostname.html; done 
deploy-myapp-86b4b8c75d-rbhfl 
deploy-myapp-86b4b8c75d-rbhfl 
deploy-myapp-86b4b8c75d-rbhfl 


测试 完成 后 ， 为 了 保证 本 章 后 续 的 其 他 使 用 效果 测试 不 受 其 影 
啊 ， 建 议 将 其 关闭 。 当 然 ， 用 户 也 可 以 使 用 "kubectl edit” 命 令 直 接 编 
辑 活动 Service 对 象 的 配置 清单 。 


6.3 ”服务 发 现 


微服 务 意味 着 存在 更 多 的 独立 服务 ， 但 它们 并 非 独 立 的 个 体 ， 而 
是 存在 着 复杂 的 依赖 关系 且 彼 此 之 间 通 党 需要 进行 非常 频 党 地 交互 和 
通信 的 群体 。 然 和 而， 建立 通 信之 前 ， 服 务 和 服务 之 间 该 如 何 获知 彼此 
的 地 址 呢 ? 在 Kubernetes 系 统 上 ，Service 为 Pod 中 的 服务 类 应 用 提供 了 
一 个 稳定 的 访问 入 口 ， 但 Pod 客 户 端 中 的 应 用 如 何 得 知 某 个 特定 
Service 资 源 的 IP 和 端口 呢 ? 这 个 时 候 就 需要 引入 服务 发 现 (Service 
Discovery) 的 机 制 。 


6.3.1 服务 发 现 概述 


简单 来 说 ， 服 务 发 现 束 是 服务 或 者 应 用 之 间 互 相 定位 的 过 程 。 不 
过 ， 服 务 发 现 并 非 狐 概念 ， 传 统 的 单 体 应 用 架构 时 代 也 会 用 到 ， 只 不 
过 单 体 应 用 的 动态 性 不 强 ， 更 新 和 重新 发 布 的 频 度 较 低 ， 通 第 以 月 其 
至 以 年 计 ， 基 本 上 不 会 进行 目 动 伸 缩 ， 因 此 服务 发 现 的 概念 无 须 显 性 
强调 。 在 传统 的 单 体 应 用 网 络 位 置 发 生变 化 时 ， 由 IT 运 维 人 员 手 工 更 
新 一 下 相关 的 配置 文件 基本 上 就 能 解决 问题 。 但 在 微服 务 应 用 场景 
中 ， 应 用 说 拆 分 成 从 多 的 小 服务 ， 它 们 按 需 创建 且 变 动 频繁 ， 配 置信 
思 基 本 无 法 事 和 匈 写 入 配置 文件 中 并 及 时 跟踪 和 反映 动态 变化 ， 因 此 服 
务 发 现 的 重要 性 便 随 之 凸显 。 


服务 发 现 机 制 的 基本 实现 ， 一 般 是 事先 部 署 好 一 个 网 络 位置 较 为 
稳定 的 服务 注册 中 心 〈 也 称 为 服务 总 线 ) ， 服 务 提 供 者 服务 端 ) 向 
注册 中 心 广 册 目 己 的 位 置信 息 ， 并 在 变动 后 及 时 予以 更 新 ， 相 应 地 ， 
服务 消费 者 则 周期 性 地 从 注册 中 心 获取 服务 提供 者 的 最 新 位 置信 息 从 
而 “发 现 ? 要 访问 的 目标 服务 资源 。 复 杂 的 服务 发 现 机 制 还 能 够 让 服务 
提供 者 提供 其 描述 信息 、 状 态 信息 及 资源 使 用 信息 等 ， 以 供 消 费 者 实 
现 更 为 复杂 的 服务 选择 逻辑 。 


实践 中 ， 根 据 服务 发 现 过 程 的 实现 方式 ， 服 务 发 现 还 可 分 为 两 种 
类 型 : 客户 端 发 现 和 服务 端 发 现 。 


-客户 端 发 现 ， 由 客户 端 到 服务 注册 中 心 发 现 其 依赖 到 的 服务 的 相 
天 信息 ， 因 此 ， 它 需要 内 置 特定 的 服务 发 现 程序 和 发 现 逻 辑 。 


.服务 端 发 现 : 这 种 方式 需要 额外 用 到 一 个 称 为 中 央 路 由 需 或 服务 
均衡 右 的 组 件 ， 服 务 消 费 首 将 请 求 发 往 中 央 路 由 右 或 者 负载 均衡 器 ， 
由 它们 负责 查询 服务 注册 中 心 获取 服务 提供 者 的 位 置信 息 ， 并 将 服务 
消费 者 的 请 求 转 发 给 服务 提供 者 。 


由 此 可 见 ， 服 务 注 册 中 心 是 服务 发 现 得 以 落地 的 核心 组 件 。 事 实 
上 ，DNS 可 以 算是 最 为 原始 的 服务 发 现 系统 之 一 ， 不 过 ， 在 服务 的 动 
态 性 很 强 的 场景 中 ，DNS 记 录 的 传播 速度 可 能 会 跟 不 上 服务 的 变更 速 
度 ， 因 此 它 并 不 适用 于 微服 务 环境 。 男 外 ， 传 统 实践 中 ， 常 见 的 服务 
注册 中 心 是 ZooKeeper 和 etcd 等 分 布 式 键 值 存储 系统 ， 不 过 ， 它 们 只 能 


提供 基本 的 数据 存储 功能 ， 距 离 实现 完整 的 服务 发 现 机 制 还 有 大 量 的 
二 次 开发 任务 需要 完成 。 另 外 ， 它 们 更 注重 数据 的 一 致 性 ， 这 与 有 着 
更 高 的 服务 可 用 性 有 要求 的 微服 务 发 现场 景 中 的 需求 不 太 相 符 。 


Netflix 的 Eureka 是 目前 较为 流行 的 服务 发 现 系统 之 一 ， 它 是 专门 
开发 用 来 实现 服务 发 现 的 系统 ， 以 可 用 性 目的 为 和 完 ， 可 以 在 多 种 故障 
期 间 保持 服务 发 现 和 服务 注册 的 功能 可 用 ， 其 设计 原则 遵从 “存在 少量 
的 错误 数据 ， 辟 比 完全 不 可 用 要 好 ”。 男 一 个 同 级 别 的 实现 是 Consul， 
它 是 由 HashiCorp 公 司 提供 的 商业 产品 ， 不 过 该 公司 还 提供 了 一 个 开源 
基础 版 本 。 它 于 服务 发 现 的 基础 功能 之 外 还 提供 了 多 数据 中 心 的 部 署 
能 力 等 一 众 出 色 的 特性 。 


尽管 传统 的 DNS 系统 不 适 于 微服 务 环境 中 的 服务 发 现 ， 但 
SkyDNS 项 目 〈 后 来 称 kubedns) 却 是 一 个 有 趣 的 实现 ， 它 结合 了 古老 
的 DNS 技术 和 时 旷 的 Go 语言 、Raft 算 法 ， 并 构建 于 etcd 存 储 系统 之 
上 ， 为 Kubernetes 系 统 实现 了 一 种 服务 发 现 机 制 。Service 资 源 为 
Kubernetes 提 供 了 一 个 较为 稳定 的 抽象 层 ， 这 有 点 类 似 于 服务 端 发 现 
的 方式 ， 于 是 也 就 不 存在 DNS 服务 的 时 间 窗 口 的 问题 。 


Kubernetes 目 1.3 版 本 开始 ， 其 用 于 服务 发 现 的 DNS 更 新 为 了 
kubeDNS， 而 类 似 的 另 一 个 基于 较 新 的 DNS 的 服务 发 现 项 目 是 由 
CNCF (Cloud Native Computing Foundation) 孵化 的 CoreDNS， 它 基于 
Go 语言 开发 ， 通 过 串 接 一 组 实现 DNS 功能 的 插件 的 插件 链 进 行 工 作 。 
自 Kubernetes 1.11 版 本 起 ，CoreDNS 取 代 kubeDNS 成 为 默认 的 DNS 附 
件 。 不 过 ，Kubernetes 依 然 文 持 使 用 环境 变量 进行 服务 发 现 。 


6.3.2 ”服务 发 现 方式 : 环境 变量 


创建 Pod 资 源 时 ，kubelet 会 将 其 所 属 名 称 空 间 内 的 每 个 活动 的 
Service 对 象 以 一 系列 环境 变量 的 形式 注入 其 中 。 它 支持 使 用 
Kubernetes Service 环 境 变 量 以 及 与 Docker 的 links 兼 容 的 变量 。 


(1) Kubernetes Service 环 境 变 量 


Kubernetes 为 每 个 Service 资 源 生 成 包括 以 下 形式 的 环境 变量 在 内 
有 一 系 列 环 过 变量 ， 在 同一 名 称 空间 中 创建 的 Pod 对 象 都 会 自动 拥有 
这 些 变量 。 


‘{SVCNAME} SERVICE HOST 


{SVCNAME} SERVICE PORT 


QS 注意 “如果 SVCNAME 中 使 用 了 连接 线 ， 那 么 Kubernetes 会 
在 定义 为 环境 变量 时 将 其 转换 为 下 划 线 。 


(2) Docker Link 形 式 的 环境 变量 


Docker 使 用 --link 选 项 实现 容器 连接 时 所 设置 的 环境 变量 形式 ， 具 
体 使 用 方式 请 参考 Docker 的 相关 文档 。 在 创建 Pod 对 象 时 ，Kubernetes 
也 会 将 与 此 形式 兼容 的 一 系列 环境 变量 注入 Pod 对 象 中 。 


例如 ， 在 Service 资 源 myapp-svc 创 建 后 创建 的 Pod 对 象 中 查看 可 用 
的 环境 变量 ， 其 中 以 MYAPP_SVC_SERVICE 开 头 的 表示 Kubernetes 
Service 环 境 变量 ， 名 称 中 不 包含 *SERVICE” 字 符 串 的 环境 变量 为 
Docker Link 形 式 的 环境 变量 : 


/# printenv | grep MYAPP 
MYAPP_SVC_PORT_80_TCP_ADDR=10.107 .208 .93 
MYAPP_SVC_PORT_80_TCP_PORT=80 

MYAPP_SVC_PORT_ 80_TCP_PROTO=tcp 
MYAPP_SVC_PORT_80_TCP=tcp://10.107.208.93:80 


MYAPP_SVC_SERVICE_HOST=10 .107 .208.93 
MYAPP_SVC_SERVICE_PORT=80 
MYAPP_SVC_PORT=tcp://10.107.208.93:80 


基于 环境 变量 的 服务 发 现 其 功能 简单 、 易 用 ， 但 存在 一 定 的 局 
限 ， 例 如 ， 仅 有 那些 与 创建 的 Pod 对 象 在 同一 名 称 空 间 中 且 事 先 存在 
的 Service 对 象 的 信息 才 会 以 环境 变量 的 形式 注入 ， 那 些 处 于 非 同 一 名 
尔 空 间 ， 或 者 是 在 Pod 资 源 创 建 之 后 才 创 建 的 Service 对 象 的 相关 环境 
变量 则 不 会 被 添加 。 笠 而， 基于 DNS 的 发 现 机 制 并 不 存在 此 类 限制 。 


6.3.3 ClusterDNS 和 服务 发 现 


Kubernetes 系 统 之 上 用 于 名 称 解 析 和 服务 发 现 的 ClusterDNS 是 集群 
的 核心 附件 之 一 ， 集 群 中 创建 的 每 个 Service 对 象 ， 都 会 由 其 自动 生成 
相关 的 资源 记录 。 默 认 情 况 下 ， 集 群 内 各 Pod 资 源 会 自动 配置 其 作为 
并 在 其 DNS 搜索 列表 中 包含 它 所 属 名 称 空 间 的 域名 
口 祥 X 

无 论 是 使 用 kubeDNS 还 是 CoreDNS， 它 们 提供 的 基于 DNS 的 服务 
发 现 解决 方案 都 会 负责 解析 以 下 资源 记录 (Resource Record) 类 型 以 
实现 服务 发 现 。 


(1) 拥有 ClusterIP 的 Service 资 源 ， 需 要 具有 以 下 类 型 的 资源 记 


'A 记 录 :，<service>.<ns>.SVc.<Zone>. <ttl> IN A <cluster-ip> 


.SRV 记 录 : _<port>._<proto>.<service>.<ns>.svc.<zone>. <ttl> IN 
SRV <weight> <priority> <port-number> <service>.<ns>.svc.<zone> 


.PTR 记 录 : <d>.<c>.<b>.<a>.in-addr.arpa. <ttl> IN PTR <service>. 
<ns>.svc.<zone> 


(2) Headless 类 型 的 Service 资 源 ， 需 要 具有 以 下 类 型 的 资源 记 


录 。 
“A 记录 : <service>.<ns>.svc.<zone>. <ttl> IN A <endpoint-ip> 


.SRV 记 录 : _<port>._<proto>.<service>.<ns>.svc.<zone>. <ttl> IN 
SRV <weight> <priority> <port-number> <hostname>.<service>.<ns>.svc. 
<zone> 


.PTR 记 录 : <d>.<c>.<b>.<a>.in-addr.arpa. <ttl> IN PTR 
<hostname>.<service>.<ns>.svc.<zone> 


(3) ExternalName 类 型 的 Service 资 源 ， 需 要 具有 CNAME 类 型 的 
资源 记录 。 


.CNAME 记 了 录 : <service>.<ns>.svc.<zone>. <ttl> IN CNAME 
<extname> 


名 称 解析 和 服务 发 现 是 Kubernetes 系 统 许多 功能 得 以 实现 的 基础 
服务 ， 它 通 间 是 集群 安 朔 完成 后 应 该 立即 部 署 的 附加 组 件 。 使 用 
kubeadm 初 始 化 一 个 集群 时 ， 它 甚至 会 目 动 进行 部 署 。 


6.3.4 服务 发 现 方 式 : DNS 


创建 Service 资 源 对 象 时 ，ClusterDNS 会 为 它 自 动 创建 资源 记录 用 
于 名 称 解 析 和 服务 注册 ， 于 是 ，Pod 资 源 可 直接 使 用 标准 的 DNS 名 称 
来 访问 这 些 Service 资 源 。 每 个 Service 对 象 相 关 的 DNS 记录 包含 如 下 两 


个 。 
{SVCNAME}.{NAMESPACE}.{CLUSTER_ DOMAIN} 
‘{SVCNAME}.{NAMESPACED}.svc.{CLUSTER_ DOMAIN} 


另外 ， 在 前 面 第 2 章 的 部 署 参 数 中 , “--cluster-dns” 指 定 了 集群 DNS 
服务 的 工作 地 址 ，“--cluster-domain” 定 义 了 集群 使 用 的 本 地 域名 ， 
此 ， 系 统 初 始 化 时 默认 会 将 “cluster.local.” 和 主机 所 在 的 域 “ilinux.io.” 作 
为 DNS 的 本 地 域 使 用 ， 这 些 信 息 会 在 Pod 创 建 时 以 DNS 配置 的 相关 信 
息 注入 它 的 /etc/resolv.conf 配 置 文件 中 。 例 如 ， 在 此 前 创建 的 用 于 交互 
式 Pod 资 源 的 客户 端 中 查看 其 配置 ， 命 令 如 下 : 


/ # cat /etc/resolv.conf 
nameserver 10.96.0.10 
search default.svc.cluster.local svc.cluster.local cluster .local ilinux.io 


上 述 search 参 数 中 指定 的 DNS 各 搜索 域 ， 是 以 次 序 指定 的 几 个 域 
名 后 缀 ， 具 体 如 下 所 示 。 


'{NAMESPACE}.svc.{CLUSTER DOMAIN 上 上 : 如 
default.svc.cluster.local ° 


‘svc.{CLUSTER DOMAIN}: 如 svec.cluster.local ° 
{CLUSTER DOMAIN}: 如 clusterlocal 。 
{fWORK_ NODE DOMAIN}: 如 ilinux.io。 


例如 ， 在 此 前 创建 的 用 于 交互 式 Pod 客 户 端 中 尝试 请 求解 析 
myapp-svc 的 相关 DNS 记录 : 


/ # nslookup myapp-svc.default 
Server: 10.96.0.10 
Address 1: 10.96.0.10 kube-dns.kube-system,.svc.cluster.1local 


Name: myapp-svc 
Address 1: 10.107.208.93 myapp-svc.default.svc.cluster.1local 


解析 时 , “myapp-svc” 服 务 名 称 的 搜索 次 序 依次 是 
default.svc.cluster.local 、svc.clusterlocal 、clusterlocal 和 ilinux.io， 此 
基于 DNS 的 服务 发 现 不 受 Service 资 源 所 在 的 名 称 空 间 和 创建 时 间 的 限 
制 。 上 面 的 解析 结果 也 正 是 默认 的 default 名 称 空 间 中 创建 的 myapp-svc 
服务 的 IP 地 址 。 


6.4 服务 又 露 


Service 的 卫 地 址 仅 在 集群 内 可 达 ， 然 而 ， 总 会 有 些 服务 需要 又 露 
到 外 部 网 络 中 接受 各 类 客户 端的 访问 ， 例 如 分 层 架 构 应 用 中 的 前 端 
Web 应 用 程序 等 。 此 时 ， 就 需要 在 集群 的 边缘 为 其 添加 一 层 转 发 机 
制 ， 以 实现 将 外 部 请 求 流量 接 入 到 集群 的 Service 资 源 之 上 ， 这 种 操作 
也 称 为 发 布 服务 到 外 部 网 络 中 。 


6.4.1 Service 类 型 


Kubernetes 的 Service 共 有 四 种 类 型 : ClusterIP、NodePort、 
LoadBalancer 和 ExternalName。 


ClusterIP: 通过 集群 内 部 耿 地 址 又 露 服务 ， 此 地 址 仅 在 集群 内 部 
可 达 ， 而 无 法 被 集群 外 部 的 客户 端 访 问 ， 如 图 6-8 所 示 。 此 为 默认 的 


Service 类 型 。 


:NodePort 这 种 类 型 建立 在 ClusterIP 类 型 之 上， 其 在 每 个 节点 的 了 
地 址 的 某 静 态 端口 (NodePort) 骏 露 服务 ， 因 此 ， 它 依然 会 为 Service 分 
配 集群 I[P 地 址 ， 并 将 此 作为 NodePort 的 路 由 目标 。 简 单 来 说 ，NodePort 
类 型 就 是 在 工作 世上 点 的 卫 地 址 上 选择 一 个 端口 用 于 将 集群 外 部 的 用 户 
请 求 转发 至 目标 Service 的 ClusterIP 和 Port， 因 此 ， 这 种 类 型 的 Service 既 
可 如 ClusterIP 一 样 受到 集群 内 部 客户 端 Pod 的 访问 ， 也 会 受到 集群 外 部 
客户 端 通过 套 接 字 <NodeIP>: <NodePort> 进 行 的 请 求 。 
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图 6-8 ”NodePort Service 类 型 


.LoadBalancer: 这 种 类 型 建构 在 NodePort 类 型 之 上 ， 其 通过 cloud 
provider 提 供 的 负载 均衡 器 将 服务 暴露 到 集群 外 部 ， 因 此 LoadBalancer 
一 样 具 有 NodePort 和 ClusterIP。 人 简 而 言 之 ， 一 个 LoadBalancer 类 型 的 
Service 会 指向 关联 至 Kubernetes 集 群 外 部 的 、 切 实 存在 的 某 个 负载 均衡 
设备 ， 该 设备 通过 工作 届 点 之 上 的 NodePort 回 集群 内 部 发 送 请 求 流量 ， 
如 图 6-9 所 示 。 例 如 Amazon 云 计算 环境 中 的 ELB 实 例 即 为 此 类 的 负载 均 
衡 设 备 。 此 类 型 的 优势 在 于 ， 它 能 够 把 来 自 于 集群 外 部 客户 端的 请 求 
调度 至 所 有 节点 (或 部 分 节点 ) 的 NodePort 之 上 ， 而 不 是 依赖 于 客户 端 
自行 决定 连接 至 哪个 节点 ， 从 而 避免 了 因 客 户 端 指定 的 闻 点 故障 而 导 
致 的 服务 不 可 用 。 


:ExternalName: 其 通过 将 Service 映 射 至 由 externalName 字 段 的 内 容 
指定 的 主机 名 来 暴露 服务 ， 此 主机 名 需要 被 DNS 服 务 解析 至 CNAME 类 
型 的 记录 。 换 言 之 ， 此 种 类 型 并 非 定义 由 Kubernetes 集 群 提 供 的 服务 ， 
而 是 把 集群 外 部 的 某 服务 以 DNS CNAME 记 录 的 方式 映射 到 集群 内 ， 从 


而 让 集群 内 的 Pod 资 源 能 够 访问 外 部 的 Service 的 一 种 实现 方式 ， 如 图 6- 
10 所 示 。 因 此 ， 这 种 类 型 的 Service 没 有 ClusterIP 和 NodePort， 也 没有 标 
签 选择 器 用 于 选择 Pod 资 源 ， 因 此 也 不 会 有 Endpoints 存 在 。 


前 面 章 节 中 创建 的 myapp-svc 即 为 默认 的 ClusterIP 类 型 Service 资 
源 ， 它 仅 能 接收 来 自 于 集群 中 的 Pod 对 象 中 的 客户 端 程序 的 访问 请 求 。 
如 若 需 要 将 Service 资 源 发 布 至 网 络 外 部 ， 应 该 将 其 配置 为 NodePort 或 
LoadBalancer 类 型 ， 而 若 要 把 外 部 的 服务 发 布 于 集群 内 容 供 Pod 对 象 使 
用 ， 则 需要 定义 一 个 ExternalName 类 型 的 Service 资 源 。 如 若 使 用 kube- 
dns， 那 么 这 种 类 型 的 实现 将 依赖 于 1.7 及 其 以 上 版 本 的 Kubernetes 版 
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图 6-9 LoadBalancer 类 型 的 Service 
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图 6-10 ”ExternalName 类 型 的 Service 


6.4.2 ”NodePort 类 型 的 Service 资 产 


NodePort 即 节点 Port， 通 党 在 安装 部 署 Kubernetes 集 群 系统 时 会 预 
留 一 个 端口 范围 用 于 NodePort， 默 认为 30000~32767 之 间 的 端口 。 与 
ClusterIP 类 型 的 可 省 略 .spec.type 属 性 所 不 同 的 是 ， 定 义 NodePort 类 型 的 
Service 资 源 时 ， 需 要 通过 此 属性 明确 指定 其 类 型 名 称 。 例 如 ， 下 面 配 
置 清 单 中 定义 的 Service 资 源 对 象 myapp-svc-nodeport， 它 使 用 了 
NodePort 类 型 ， 且 人 为 指定 其 节点 端口 为 32223; 


kind: Service 
apiVersion: v1 
metadata: 

name: myapp-svc-nodeport 

spec: 

type: NodePort 

selector: 
app: myapp 

ports: 

- protocol: TCP 
port: 80 
targetPort: 80 
nodePort: 32223 


实践 中 ， 并 不 吉 励 用 户 自 定义 使 用 的 太 点 端口 ， 除 非 事 先 能 够 明 
确 知 道 它 不 会 与 某 个 现存 的 Service 资 源 产 生 冲 突 。 无 论 如 何 ， 只 要 没 
有 特别 需求 ， 留 给 系统 自动 配置 总 是 较 好 的 选择 。 使 用 创建 命令 创建 
上 面 的 Service 对 象 后 即 可 了 解 其 运行 状态 : 


~]$ kubect1l get services myapp-svc-nodeport 
NAME TYPE CLUSTER-IPEXTERNAL-IP PORT(S) AGE 
myapp-svc-nodeport NodePort 10.109.234.108 <none> 80:32223/TCP 3S 


命令 结果 显示 ，NodePort 类 型 的 Service 资 源 依 然 会 税 配 置 
ClusterIP， 事 实 上 ， 它 会 作为 节点 从 NodePort 接 入 流量 后 转发 的 目标 地 
址 ， 目 标 端 口 则 是 与 Service 资 源 对 应 的 spec.ports.port 属 性 中 定义 的 并 
口 ， 如 图 6-11 所 示 。 
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图 6-11 ”请求 流 量 转 发 过 程 


因此 ， 对 于 集群 外 部 的 客户 端 来 说 ， 它 们 可 经 由 任何 一 个 入 点 的 
节点 卫 及 端口 访问 NodePort 类 型 的 Service 资 源 ， 而 对 于 集群 内 的 Pod 客 
户 端 来 说 ， 依 然 可 以 通过 ClusterIP 对 其 进行 访问 。 


6.4.3” ”LoadBalancer 类 型 有 的 Service 资 源 


NodePort 类 型 的 Service 资 源 虽 然 能 够 于 集群 外 部 访问 得 到 ， 但 外 
部 客户 端 必须 得 事先 得 知 NodePort 和 集群 中 至 少 一 个 节点 的 IP 地 址 ， 
且 选 定 的 厄 点 发 生 故 障 时 ， 客 户 端 还 得 自行 选择 请 求 访问 其 他 的 市 
点 。 男 外 ， 和 集群 节点 很 可 能 是 某 IaaS 云 环境 中 使 用 私有 IP 地 址 的 VM， 
或 者 是 IDC 中 使 用 私有 地 址 的 物理 机 ， 这 类 地 址 对 互联 网 客户 端 不 可 
达 ， 因 此 ， 一 般 还 应 该 在 集群 之 外 创建 一 个 具有 公 网 IP 地 址 的 负载 均 
i ， 由 它 接 入 外 部 客户 端的 请 求 并 调度 至 集群 节点 相应 的 NodePort 


IaaS 云 计算 环境 通常 提供 了 LBaaS (Load Balancer as a Service) 服 
务 ， 它 人 允许 租户 动态 地 在 目 己 的 网 络 中 创建 一 个 负载 均衡 设备 。 那 些 
部 署 于 此 类 环境 之 上 的 Kubernetes 集 群 在 创建 Service 资 源 时 可 以 直接 
调用 此 接口 按 需 创建 出 一 个 软 负 载 均衡 妖 ， 而 具有 这 种 功能 的 Service 
资源 即 为 LoadBalancer 类 型 。 不 过 ， 如 果 Kubernetes 部 署 于 裸 的 物理 服 
务 器 之 上 上， 系统 管理 员 也 可 以 目 行 手动 部 署 一 个 负载 均衡 右 (推荐 使 
用 元 余 配置 ) ， 并 配置 其 将 请 求 流量 调度 至 各 节点 的 NodePort 之 上 即 


可 。 


下 面 是 一 个 LoadBalancer 类 型 的 Service 资 源 配 置 清单 ， 若 
Kubernetes 系 统 满足 其 使 用 条 件 ， 即 可 目 行 进行 应 用 测试 。 需 要 注意 
的 是 ， 有 些 环境 中 可 能 还 需要 为 Service 资 源 的 配置 定义 添加 
Annotations， 必 要 时 请 自行 参考 Kubernetes 文 档 中 的 说 明 : 


kind: Service 
apiVersion: v1 
metadata: 

name: myapp-svc-1b 

spec: 

type: LoadBalancer 

selector: 
app: myapp 

ports: 

- protocol: TCP 
port: 80 
targetPort: 80 
nodePort: 32223 


进一步 地 ， 在 IaaS 环 境 文 持 手动 指定 IP 地 址 时 ， 用 户 还 可 以 使 
用 .spec.loadBalancerIP 指 定 创建 的 负载 均衡 器 使 用 的 IP 地 址 ， 并 可 使 
用 .spec.loadBalancerSourceRanges 指 定 负 载 均 衡 右 允许 的 客户 端 来 源 的 
地 址 范围 。 


6.4.4 上 ExternalName Service 


ExternalName 类 型 的 Service 资 源 用 于 将 集群 外 部 的 服务 发 布 到 集 
群 中 以 供 Pod 中 的 应 用 程序 访问 ， 因 此 ， 它 不 需要 使 用 标签 选择 絮 关 
联 任何 的 Pod 对 象 ， 但 必须 要 使 用 Spec.externalName 属 性 定义 一 个 
CNAME 记 录用 于 返回 外 部 真正 提供 服务 的 主机 的 别名 ， 而 后 通过 
CNAME 记 录 值 获取 到 相关 主机 的 JP 地 址 。 


下 面 是 一 个 ExternalName 类 型 的 Service 资 源 示例 ， 名 为 external- 
redis-svc， 相 应 的 externalName 为 “redis.ilinux.io”: 


kind: Service 
apiVersion: v1 
metadata.: 
name: external-redis-svc 
namespace: default 
spec: 
type: ExternalName 
externalName: redis.ilinux.io 
ports: 
- protocol: TCP 
port: 6379 
targetPort: 6379 
nodePort: 0 
selector: {} 


待 Service 资 源 external-redis-svc 创 建 完 成 后 ， 各 Pod 对 和 象 即 可 通过 
external-redis-svc 或 其 FQDN 格 式 的 名 称 external-redis- 
svc.default.svc.cluster.local 访 问 相 应 的 服务 。ClusterDNS 会 将 此 名 称 以 
CNAME 格 式 解析 为 .spec.externalName 字 段 中 的 名 称 ， 而 后 通过 DNS 服 
务 将 其 解析 为 相应 的 主机 的 IP 地 址 。 例 如 ， 通 过 此 前 创建 的 交互 Pod 资 
源 客 户 端 进行 服务 名 称 解 析 : 


/ # nslookup external-redis-svc 
Server: 10.96.0.10 
Address 1: 10.96.0.10 kube-dns.kube-system,svc.cluster.1local 


Name: external-redis-svc 
Address 1: 45.54.44.100 100.44.54.45.ptr.anycast.net 


由 于 ExternalName 类 型 的 Service 资 源 实 现 于 DNS 级 别 ， 客 户 端 将 
直接 接 入 外 部 的 服务 而 完全 不 需要 服务 代理 ， 因 此 ， 它 也 无 须 配 置 
ClusterIP， 此 种 类 型 的 服务 也 称 为 Headless Service 。 


6.5 ” Headless 类 型 的 Service 痪 源 


Service 对 象 隐藏 了 各 Pod 资 源 ， 并 负责 将 客户 端的 请 求 流量 调度 
至 该 组 Pod 对 象 之 上。 不 过 ， 偶 尔 也 会 存在 这 样 一 类 需求 : 客户 端 需 
要 直接 访问 Service 资 源 后 端的 所 有 Pod 资 源 ， 这 时 束 应 该 回 客 户 端 桑 
露 每 个 Pod 资 源 的 IP 地 址 ， 而 不 再 是 中 间 层 Service 对 象 的 ClusterIP， 这 
种 类 型 的 Service 资 源 便 称 为 Headless Service 。 


Headless Service 对 象 没有 ClusterIP， 于 是 kube-proxy 便 无 须 处 理 此 
类 请 求 ， 也 束 更 没有 了 负载 均衡 或 代理 它 的 需要 。 在 前 端 应 用 拥有 目 
有 的 其 他 服务 发 现 机 制 时 ，Headless Service 即 可 省 去 定义 ClusterIP 的 
需求 。 至 于 如 何 为 此 类 Service 资 源 配置 卫 地 址 ， 则 取决 于 它 的 标签 选 
择 器 的 定义 。 


.具有 标签 选择 器 : 端点 控制 器 (Endpoints Controller) 会 在 API 中 
为 其 创建 Endpoints 记 录 ， 并 将 ClusterDNS 服 务 中 的 A 记录 直接 解析 到 
此 Service 后 端的 各 Pod 对 象 的 了 P 地 址 上 。 


.没有 标签 选择 器 : 端点 控制 器 (Endpoints Controller) 不 会 在 API 
中 为 其 创建 Endpoints 记 录 ，ClusterDNS 的 配置 分 为 两 种 情形 ， 对 
ExternalName 类 型 的 服务 创建 CNAME 记 录 ， 对 其 他 三 种 类 型 来 说 ， 为 
那些 与 当前 Service 共 享 名 称 的 所 有 Endpoints 对 象 创建 一 条 记录 。 


6.5.1 创建 Headless Service 资 源 


配置 Service 资 源 配置 清单 时 ， 只 需要 将 ClusterIP 字 段 的 值 设置 
为 "None" 即 可 将 其 定义 为 Headless 类 型 ° 下 面 是 一 个 Headless Service 资 
源 配置 清单 示例 ， 它 拥有 标签 选择 需 : 


kind: Service 
apiVersion: v1 
metadata: 
name: myapp-headless-svc 
spec: 
ClusterIP: None 
selector: 
app: myapp 
ports: 
- port: 80 
targetPort: 80 
name: httpport 


使 用 资源 创建 命令 “kubectl create” 或 “kubectl apply” 完 成 资源 创建 
后 ， 使 用 相关 的 查看 命令 获取 Service 资 源 的 相关 信息 便 可 以 看 出 ， 它 
没有 ClusterIP， 不 过 ， 如 采 标 签 选 择 器 能 够 匹配 到 相关 的 Pod 资 源 ， 它 
便 拥 有 Endpoints 记 录 ， 这 些 Endpoints 对 象 会 作为 DNS 资源 记录 名 称 
myapp-headless-svc 查 询 时 的 A 记录 解析 结果 : 


~]$ kubectl1 describe svc myapp-headless-svc 


Endpoints: 10.244.1.113:80,10.244.2.13:80,10.244.3.104:80 


6.5.2 ”Pod 资 源 发 现 


根据 Headless Service 的 工作 特性 可 知 ， 它 记录 于 ClusterDNS 的 A 记 
录 的 相关 解析 结果 是 后 端 Pod 资 源 的 IP 地 址 ， 这 就 意味 着 客户 端 通过 此 
Service 资 源 的 名 称 发 现 的 是 各 Pod 资 源 。 下 面 依然 选择 创建 一 个 专用 
的 测试 Pod 对 象 ， 而 后 通过 其 交互 式 接口 进行 测试 : 


~]$ kubect1l run cirros-$RANDOM --rm -it --image=cirros -- sh 


/ # nslookup myapp-headless-svc 
Server: 10.96.0.10 
Address 1: 10.96.0.10 kube-dns.kube-system,.svc.cluster.1local 


Name : myapp-headless-svc 
Address 1: 10.244.2.13 
Address 2: 10.244.1.113 
Address 3: 10.244.3.104 


其 解析 结果 正 是 Headless Service 通 过 标签 选择 器 关联 到 的 所 有 Pod 
资源 的 IP 地 址 。 于 是 ， 客 户 端 癌 此 Service 对 象 发 起 的 请 求 将 直接 接 入 
到 Pod 资 源 中 的 应 用 之 上 ， 而 不 再 由 Service 资 源 进行 代理 转发 ， 它 每 
次 接 入 的 Pod 资 源 则 是 由 DNS 服务 需 接 收 到 查询 请 求 时 以 轮 询 

(roundrobin) 的 方式 返回 的 IP 地 址 。 


6.6 ”Ingress 资 源 


Kubernetes 提 供 了 两 种 内 建 的 云端 负载 均衡 机 制 (cloud load 
balancing) 用 于 发 布 公 共 应 用 ， 一 种 是 工作 于 传输 层 的 Service 资 源 ， 
它 实现 的 是 “ITCP 人 负载 均衡 希 ”， 另 一 种 是 mgress 资 源 ， 它 实现 的 
是 “HTTP (S) 负载 均衡 器 ”。 


(1) TCP 负 载 均衡 器 


无 论 是 iptables 还 是 ipvs 模 型 的 Service 资 源 都 配置 于 Linux 内 核 中 的 
Netfilter 之 上 进行 四 层 调 度 ， 是 一 种 类 型 更 为 通用 的 调度 右 ， 文 持 调度 
HTTP、MySQL 等 应 用 层 服务 。 不 过 ， 也 正 是 由 于 工作 于 传输 层 从 而 
使 得 它 无 法 做 到 类 似 番 载 HTTPS 中 的 SSL 会 话 等 一 类 操作 ， 也 不 文 持 
基于 UREIL 的 请 求 调 度 机 制 ， 而 且 ，Kubernetes 也 不 文 持 为 此 类 负载 均 
衡器 配置 任何 类 型 的 健康 状态 检查 机 制 。 


(2) HTTP (S) 负载 均衡 器 


HTTP (S) 负载 均衡 器 是 应 用 层 负载 均衡 机 制 的 一 种 ， 文 持 根 据 
环境 做 出 更 好 的 调度 决策 。 与 传输 层 调 度 锅 相 比 ， 它 提供 了 诸如 可 目 
和 并 文 持 多 种 类 型 的 后 端 服务 器 健康 
> 全 今 查 | 。 


6.6.1 Ingress 和 Ingress Controller 


Kubernetes 中 ，Service 资 源 和 Pod 资 源 的 了 了 地 址 仅 能 用 于 集群 网 络 
内 部 的 通信 ， 所 有 的 网 络 流量 都 无 法 穿 透 边界 路 由 器 (Edge Router) 
以 实现 集群 内 外 通信 。 尽 管 可 以 为 Service 使 用 NodePort 或 LoadBalancer 
类 型 通过 市 点 引入 外 部 流量 ， 但 它 依然 是 4 层 流 量 转 发 ， 可 用 的 负载 均 
衡 絮 也 为 传输 层 人 负载 均衡 机 制 。 


Ingress 是 Kubernetes API 的 标准 资源 类 型 之 一 ， 它 其 实 束 是 一 组 基 
于 DNS 名 称 (host) 或 URL 路 径 把 请 求 转发 至 指定 的 Service 资 源 的 规 
则 ， 用 于 将 集群 外 部 的 请 求 流量 转发 至 集群 内 部 完成 服务 发 布 。 然 
而 ，Ingress 资 源 上 自身 并 不 能 进行 “流量 穿 透 ”>， 它 仅 是 一 组 路 由 规则 的 集 
合 ， 这 些 规则 要 想 真 正 发 挥 作 用 还 需要 其 他 功能 的 辅助 ， 如 监听 某 套 
接 字 ， 然 后 根据 这 些 规则 的 匹配 机 制 路 由 请 求 流量 。 这 种 能 够 为 
Ingress 资 源 监听 套 接 字 并 转发 流量 的 组 件 称 为 Ingress 控 制 器 (Ingress 


Controller) 


CY 、 本 一 De 日 日 名 口 口 、 
O 注意 ”不同 于 Deployment 控 制 右 等 ，Ingress 探 制 器 并 个 直接 
运行 为 kube-controller-manager 的 一 部 分 ， 它 是 Kubernetes 集 群 的 一 个 重 


要 附件 ， 类 似 于 CoreDNS， 需 要 在 集群 上 单独 部 署 。 


Ingress 控 制 器 可 以 由 任何 具有 反 向 代理 (HTTP/HTTPS) 功能 的 服 
务 程序 实现 ， 如 Nginx、Envoy、HAProxy、Vulcand 和 Traefik 等 。 
Ingress 控 制 右 目 喘 也 是 运行 于 集群 中 的 Pod 资 源 对 象 ， 它 与 被 代理 的 运 
行为 Pod 资 源 的 应 用 运行 于 同一 网 络 中 ， 如 图 6-12 中 ingress-nginx 与 
pod1、pod3 等 的 天 系 所 示 。 
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图 6-12 Ingress 与 Ingress Controller 


男 一 方面 ， 使 用 Ingress 资 源 进 行 流量 分 发 时 ，Ingress 控 制 器 可 基于 
某 Ingress 资 源 定 义 的 规则 将 客户 端的 请 求 流量 直接 转发 至 与 Service 对 
应 的 后 端 Pod 资 源 之 上 ， 这 种 转发 机 制 会 绕 过 Service 资 源 ， 从 而 省 去 了 
由 kube-proxy 实 现 的 端口 代理 开销 。 如 图 6-12 所 示 ，Ingress 规 则 需要 由 
一 个 Service 资 源 对 象 辅助 识别 相关 的 所 有 Pod 对 象 ， 但 ingress-nginx 控 
制 器 可 经 由 api.ilinux.io 规 则 的 定义 直接 将 请 求 流量 调度 至 pod3 或 pod4 ， 
风 由 Service 对 象 API 的 再 次 转发 ，WAP 相 关 规 则 的 作用 方式 与 此 


6.6.2 ”创建 mmgress 资 源 


Ingress 资 源 是 基于 HTTP 虚 拟 主机 或 URL 的 转发 规则 ， 它 在 资源 配 
置 清 单 的 spec 字 段 中 舱 套 了 rules、backend 和 tls 等 字段 进行 定义 。 下 面 
的 示例 中 定义 了 一 个 Ingress 资 源 ， 它 包含 了 一 个 转发 规则 ， 把 发 往 
www.ilinux.io 的 请 求 代 理 给 名 为 myapp-svc 的 Service 资 源 : 


apiVersion: extensions/vibeta1 
kind: Ingress 
metadata: 
name: my-ingress 
annotations: 
kubernetes.io/ingress.class: "nginx" 
spec: 
rules: 
- host: www.ilinux.io 
http: 
paths : 
- backend : 
serviceName: myapp-svc 
servicePort: 80 


上 面 资源 清单 中 的 annotations 用 于 识别 其 所 属 的 Ingress 控 制 器 的 类 
别 ， 这 一 扩 在 集群 上 部 嗜 有 多 个 Ingress 控 制 句 时 尤为 重要 ° Ingress 
Spec 中 的 字段 是 定义 mgress 资 源 的 核心 组 成 部 分 ， 它 主要 航 套 如 下 三 
个 字段 。 


:rules<Object> : 用 于 定义 当前 mgress 资 源 的 转发 规则 列表 ; 未 由 
rules 定 义 规 则 ， 或 者 没有 匹配 到 任何 规则 时 ， 所 有 流量 都 会 转发 到 由 
backend 定 义 的 默认 后 端 。 


.backend<Object> : 默认 的 后 端 用 于 服务 那些 没有 匹配 到 任何 规 
则 的 请 求 ;， 定义 Pmgress 资 源 时 ， 至 少 应 该 定义 backend 或 rules 两 者 之 
一 ; 此 字段 用 于 让 负载 均衡 妖 指 定 一 个 全 局 默认 的 后 端 。 


tls<Object> : TLS 配 置 ， 目 前 仅 文 持 通过 默认 端口 443 提 供 服务 ; 
如 有 果 要 配置 指定 的 列表 成 员 指 向 了 不 同 的 主机 ， 则 必须 通过 SNI TLS 
扩展 机 制 来 支持 此 功能 。 


backend 对 象 的 定义 由 两 个 必 选 的 内 骨 字 上段 组 成 : serviceName 和 和 
servicePort， 分 别 用 于 指定 流量 转发 的 后 端 目标 Service 资 源 的 名 称 和 端 
回避 


rules 对 象 由 一 系列 配置 Ingress 资 源 的 host 规 则 组 成 ， 这 些 host 规 则 
用 于 将 一 个 主机 上 的 某 个 URL 路 径 映 射 至 相关 的 后 端 Service 对 象 ， 它 
的 定义 格式 如 下 : 


serviceName: <String> 
servicePort: <String> 
path: <String> 


注意 ，.spec.rules.host 属 性 值 目前 不 支持 使 用 IP 地 址 ， 也 不 支持 后 
跟 “: PORT” 格 式 的 端口 号 ， 且 此 字段 值 留 空 表示 通 配 所 有 的 主机 名 。 


ts 对 象 由 两 个 内 嵌 字 段 组 成 ， 仅 在 定义 TLS 主 机 的 转发 规则 时 才 
需要 定义 此 类 对 象 。 


:hosts: 包含 于 使 用 的 TLS 证 书 之 内 的 主机 名 称 字 符 串 列表 ， 
此 ， 此 处 使 用 的 主机 和 名 必须 匹配 tsSecret 中 的 名 称 。 


SecretName: 用 于 引用 SSL 会 话 的 secret 对 象 名 称 ， 在 基于 SNI 实 
现 多 主机 路 由 的 场景 中 ， 此 字段 为 可 选 。 


6.6.3 Ingress 资 源 类 型 


基于 HTTP 骏 露 的 每 个 Service 资 源 均 可 发 布 于 一 个 独立 的 FQDN 主 
机 名 之 上 ， 如 “www.ik8s.io”; 也 可 发 布 于 某 主 机 的 URL 路 径 之 上 ， 从 
而 将 它们 整合 到 同一 个 Web 站 点 ， 如 “www.ik8s.io/grafana”。 至 于 是 否 
需要 发 布 为 HTTPS 类 型 的 应 用 则 取决 于 用 户 的 业务 需求 。 


1. 单 Service 资 源 型 ingress 


又 露 单个 服务 的 方法 有 很 多 种 ， 如 服务 类 型 中 的 NodePort、 
LoadBalancer 等 ， 不 过 一 样 可 以 考虑 使 用 Ingress 来 骏 露 服务 ， 此 时 只 需 
要 为 Ingress 指 定 “default backend” 即 可 。 例 如 下 面 的 示例 : 


apiVersion: extensions/vibeta1 
kind: Ingress 
metadata: 
name: my-ingress 
spec: 
backend: 
serviceName: my-svc 
servicePort: 80 


Ingress 控 制 器 会 为 其 分 配 一 个 IP 地 址 接 入 请 求 流量 ， 并 将 它们 转 


至 示例 中 的 my-svc 后 端 。 
2. 基 于 URL 路 径 进 行 流 量 分 发 


王 直 拆 分 或 微服 务 架 构 中 ， 每 个 小 的 应 用 都 有 其 专用 的 Service 资 
源 驼 露 服务 ， 但 在 对 外 开放 的 站 点 上 ， 它 们 可 能 是 财经 、 新 闻 、 电 
商 、 无 线 端 或 API 接 口 等 一 类 的 独立 应 用 ， 可 通过 主 域名 的 URL 路 径 

(path) 分 别 接 入 ， 例 如 ，www.ilinux.io/api 、www.ilinux.io/wap 等 ， 
用 于 发 布 集群 内 名 称 为 API 和 WAP 的 Services 资 源 。 于 是 ， 可 对 应 地 创 
建 一 个 如 下 的 Ingress 资 源 ， 它 将 对 www.ilinux.io/api 的 请 求 统 统 转发 至 
API Service 资 源 ， 将 对 www.ilinux.io/wap 的 请 求 转 发 至 WAP Service 资 
产 : 


apiVersion: extensions/vibeta1 
kind: Ingress 


metadata: 
name: test 
annotations: 
ingress.kubernetes.io/rewrite-target: / 
spec: 
rules: 
- host: www.ilinux.io 
http: 
paths : 
- path: /wap 
backend: 
serviceName: wap 
servicePort: 80 
- path: /api 
backend: 
serviceName: api 
servicePort: 80 


SO 注意 “目前 ，ingress-nginx 似 乎 尚且 不 能 很 好 地 文 持 基于 
annotations 进 行 URL 映 射 。 这 就 意味 着 ， 在 ingress-nginx 上 ， 此 项 功能 
尚且 不 能 使 用 。 具 体 信 息 请 参考 这 个 链接 中 的 讨论 ， 
https://github.com/istio/istio/issues/585 。 


3. 基 于 主机 名 称 的 虚拟 主机 


上 面 类 型 2 中 描述 的 需求 ， 也 可 以 将 每 个 应 用 分 别 以 独立 的 FQDN 
主机 名 进行 输出 ， 如 wap.ik8s.io 和 api.ik8s.io， 这 两 个 主机 名 解析 到 
external LB (如 图 6-12 所 示 ) 的 IP 地 址 之 上 ， 分 别 用 于 发 布 集群 内 部 的 
WAP 和 API 这 两 个 Service 资 源 。 这 种 实现 方案 其 实 就 是 Web 站 点 部 署 中 
的 “基于 主机 名 的 虚拟 主机 ”， 将 多 个 FQDN 解 析 至 同一 个 IP 地 址 ， 然 后 
根据 “主机 头 ” (Host header) 进行 转发 。 下 面 是 以 独立 FQDN 主 机 形式 
发 布 服务 的 Ingress 资 源 示例 : 


apiVersion: extensions/vibeta1 
kind: Ingress 
metadata: 

name: test 
spec: 

rules: 

- host: api.ik8s.io 

http: 

paths: 

- backend: 
serviceName: api 
servicePort: 80 

- host: wap.ik8s.io 
http: 

paths: 


- backend : 
serviceName: wap 
servicePort: 80 


4.TLS 类 型 的 Ingress 资 源 


这 种 类 型 用 于 以 HTTPS 发 布 Service 资 源 ， 基 于 一 个 含有 私 钥 和 证 
书 的 Secret 对 象 (后 面 章节 中 会 详细 讲述 ) 即 可 配置 TLS 协 议 的 Ingress 
资源 ， 目 前 来 说 ，Ingress 资 源 仅 文 持 单 TLS 端 口 ， 并 且 还 会 外 载 TLS 会 
话 。 在 Ingress 资 源 中 引用 此 Secret 即 可 让 Ingress 控 制 右 加 载 并 配置 为 
HTTPS 服 务 。 


下 面 是 一 个 人 简单 的 TLS 类 型 的 Ingress 资 源 示例 |: 


apiVersion: extensions/vibeta1 
kind: Ingress 
metadata: 


name: no-rules-map 
spec: 
tl1s: 
- SecretName: ikubernetesSecret 
backend: 


serviceName: homesite 
servicePort: 80 


6.6.4 ”部 署 Ingress 控 制 器 (Nginx) 


Ingress 控 制 器 自身 是 运行 于 Pod 中 的 容器 应 用 ， 一 般 是 Nginx 或 
Envoy 一 类 的 具有 代理 及 负载 均衡 功能 的 守护 进程 ， 它 监视 着 来 自 于 
API Server 的 Ingress 对 象 状态 ， 并 以 其 规则 生成 相应 的 应 用 程序 专 有 格 
式 的 配置 文件 并 通过 重 载 或 重启 守护 进程 而 使 新 配置 生效 。 例 如 ， 对 
于 Nginx 来 说 ，Ingress 规 则 需要 转换 为 Nginx 的 配置 信息 。 简 单 来 说 ， 
Ingress 控 制 絮 其 实 就 是 托管 于 Kubernetes 系 统 之 上 的 用 于 实现 在 应 用 层 
发 布 服务 的 Pod 资 源 ， 它 将 跟踪 Ingress 资 源 并 实时 生成 配置 规则 。 那 
么 ， 同 样 运行 为 Pod 资 源 的 Ingress 控 制 器 进程 又 该 如 何 接 入 外 部 的 请 求 
流量 呢 ? 常用 的 解决 方案 有 如 下 两 种 。 
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; kubernetes cluster Ingress-deploy : 


图 6-13 ”使 用 专用 的 Service 对 象 为 Ingress 控 制 器 接 入 外 部 流量 


.以 Deployment 控 制 避 管理 mgress 探 制 右 的 Pod 资 源 ， 并 通过 
NodePort 或 LoadBalancer 类 型 的 Service 对 象 为 其 接 入 集群 外 部 的 请 求 流 


量 ， 这 束 意 味 着 ， 定义 一 个 Ingress 控 制 占 时 ， 必须 在 其 前 端 定义 一 个 
专用 的 Service 资 源 ， 如 图 6-13 所 示 。 


.借助 于 DaemonSet 探 制 器 ， 将 Ingress 探 制 右 的 Pod 资 源 各 上 自 以 单 一 
实例 的 方式 运行 于 集群 的 所 有 或 部 分 工作 节点 之 上 ， 并 配置 这 类 Pod 对 
象 以 hostPort (如 图 6-14a) 或 hostNetwork (如 图 6-14b) 的 方式 在 当前 
节点 接 入 外 部 流量 。 
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图 6-14 ”以 hostPort 或 hostNetwork 的 方式 为 mgress 探 制 器 接 入 外 部 流量 


以 ingress-nginx 项 目 为 例 ， 部 署 Ingress Nginx 控 制 絮 的 配置 文件 被 
切 制 存放 在 了 多 个 不 同 的 文件 中 ， 并 集中 存储 于 其 源码 deploy 子 目录 
下 ， 同 时 ， 为 了 方便 用 户 部 署 ， 它 还 将 所 需 的 资源 全 部 集成 为 一 个 配 
置 文件 mandatory.yaml: 


~]$ kubect] apply -f https://raw.githubusercontent.com/kubernetes/ingress- 
nginx/master/deploy/mandatory.yaml 


因为 需要 下 载 相关 的 镜像 文件 ， 因 此 前 面部 署 过 程 中 的 Pod 资 源 的 
创建 需要 等 待 一 段 时 间 才能 完成 ， 具 体 时 长 要 取决 于 网 络 的 可 用 状 
况 。 可 使 用 如 下 命令 持续 监控 创建 过 程 ， 待 其 状态 为 <Running” 之 后 即 
表示 运行 正名 : 


~]$ kubect] get pods -n ingress-nginx --watch 
NAME READY STATUS RESTARTS AGE 


default-http-backend-6586bc58b6-cw7c6 1/1 Running 0 3m 
nginx-ingress-controller-7675fd6cdb-kvsh2 1/1 Running 0 3m 


在 线 的 配置 清单 中 采用 了 基于 Deployment 控 制 套 部署 Imgress Nginx 
的 方式 ， 因 此 接 入 外 部 流量 之 前 还 需要 手动 为 其 创建 相关 的 NodePort 或 
LoadBalancer 类 型 的 Service 资 源 对 象 ， 下 面 的 配置 清单 示例 中 对 类 型 定 
义 了 NodePort， 并 明确 指定 了 易 记 的 端口 和 也 地址， 以 方便 用 户 使 用 : 


apiVersion: v1 
kind: Service 
metadata: 
name: nginx-ingress-controller 
namespace: ingress-nginx 
spec: 
type: NodePort 
clusterIP: 10.99.99.99 
ports: 
- port: 80 
name: http 
nodePort: 30080 
- port: 443 
name: https 
nodePort: 30443 
selector: 
app.kubernetes.io/name: ingress-nginx 


将 上 面 的 配置 信息 保存 于 文件 中 ， 如 nginx-ingress-service.yaml， 而 
后 执行 如 下 命令 完成 资源 的 创建 。 注 意 ， 其 标签 选择 器 应 该 与 
mandatory.yaml 配 置 清 单 中 的 Deployment 探 制 器 nginx-ingress-controller 
的 选择 硕 保 持 一 致 


~]$ kubect] apply -f nginx-ingress-service.yaml 


名 注意 ”如 果 读 者 的 集群 运行 支持 LBaaS 的 IaaS 云 环境 ， 则 可 
以 将 其 类 型 指定 为 LoadBalancer， 这 样 直 接 束 有 了 可 用 的 external-LB。 


确认 Service 对 象 nginx-ingress-controller 的 状态 没有 问题 后 即 可 于 集 
群 外 部 对 其 发 起 访问 测试 ， 目 标 URE 为 http:/<NodeIP>:30080 或 
http://<NodeIP>:30443 ， 确 认可 接收 到 啊 应 报 文 后 即 表示 Ingress Nginx 
部 署 完成 。 不 过 ， 本 示例 中 尚且 缺少 一 个 可 用 的 外 部 负载 均衡 器 ， 如 
图 6-13 中 所 示 的 “external-LB”， 因 此 ， 访 问 测 试 时 暂时 还 只 能 使 用 
http://<NodeIp>:<NodePort> 进行 。 


6.7 案例 : 使 用 Ingress 发 布 tomcat 


假设 有 这 样 一 套 环境 : Kubernetes 集 群 上 的 tomcat-deploy 控 制 器 生 
成 了 两 个 运行 于 Pod 次 禹 源 中 的 tomcat 实 例 ，tomcat-svc 是 将 它们 统一 又 
露 于 集群 中 的 访问 入 口 。 现 在 需要 通过 Ingress 资 源 将 tomcat-svc 发 布 给 
集群 外 部 的 客户 端 访问 。 具 体 的 需求 和 规划 如 图 6-15 所 示 。 


为 了 便于 读者 理解 ， 下 面 的 测试 操作 过 程 将 把 每 一 步 分 解 开 来 放 
酝 单 独 的 二 万 中 进行” 


6.7.1 准备 和 名称 空间 


假设 本 示例 中 创建 的 所 有 资源 都 位 于 新 建 的 testing 名 称 空 间 中 ， 与 
其 他 的 资源 在 逻辑 上 进行 隔离 ， 以 方便 管理 。 下 面 的 配置 信息 保存 于 
testing-namespace.yaml 资 源 清单 文件 中 : 


External Clients 


NodePort 小 IN [ele (= eol 
: 


<Service> 


pF 


kubernetes cluster 


Ingress-nginx-controller | 
<IngressController> ， 
ingress-nginx 


! <Service> 
' .| tomcat-sve | 
| <lneress> 


图 6-15 ”Ingress 发 布 应 用 示例 拓扑 图 


kind: Namespace 
apiVersion: v1 
metadata: 
name: testing 
labels: 
env: testing 


而 后 运行 创建 命令 完成 资源 的 创建 ， 并 确认 资源 的 存在 : 


~]$ kubect1l1 apply -f testing-namespace.yaml 
namespace "testing" created 
~]$ kubect] get namespaces testing 


NAME STATUS AGE 
testing Active 8s 


天 


6.7.2 ”部 署 tomcat 实 例 


在 此 示例 中 ，tomcat 应 用 本 里 代表 着 运行 于 tomcat 容 絮 中 的 一 个 实 
际 应 用 。 具 体 实践 中 ， 它 通常 应 该 是 包含 了 某 应 用 程序 的 war 文 件 的 镜 
像 文 件 。 下面 的 配置 清单 使 用 了 Deployment 控 制 疾 于 testing 中 部 署 
tomcat 相 关 的 Pod 对 象 ， 它 保存 于 tomcat-deploy.yaml 文 件 中 : 


apiVersion: apps/vi1 
kind: Deployment 
metadata: 
name: tomcat-deploy 
namespace: testing 
spec: 
replicas: 2 
selector: 
matchLabels: 
app: tomcat 
template: 
metadata: 
labels: 
app: tomcat 
spec: 
containers: 
- name: tomcat 
image: tomcat:8.0.50-jre8-alpine 
ports: 
- containerPort: 8080 
name: httpport 
- containerPort: 8009 
name: ajpport 


运行 资源 创建 命令 完成 Deployment 控 制 器 和 Pod 资 源 的 创建 ， 命 令 
[下 : 


~]$ kubectl1 apply -f tomcat-deploy.yaml 


人 命令 以 确认 其 成 功 完成 ， 且 各 Pod 已 经 处 于 正常 运行 状 


~]$ kubect1 get pods -n testing 

NAME READY STATUS RESTARTS AGE 
tomcat-deploy-6cf8468f7f-5d7tb 1/1 Running 0 1im 
tomcat-deploy-6cf8468f7f-9fvxx 1/1 Running 0 1m 


实践 中 ， 如 采 需 要 更 多 的 Pod 筑 源 承载 用 户 访问 ， 那 么 使 用 
Deployment 控 制 絮 的 规模 伸缩 机 制 即 可 完成 ， 或 者 直接 修改 上 面 的 配 
置 文件 并 执行 “kubectl apply” 命 令 重 新 进行 应 用 。 


6.7.3 创建 Service 资 源 


Ingress 资 源 仅 通 过 Service 资 源 识别 相应 的 Pod 资 源 ， 获 取 其 耻 和 端 
口 ， 而 后 Ingress 控 制 器 de 已 直接 进行 
通信 ， 而 不 经 由 Service 资 源 的 代理 和 调度 ， 因 此 Service 资 源 的 
cluster 对 mgress 控 制 器 来 说 一 无 所 用 。 不 过 ， 若 集群 内 的 其 他 Pod 客 

户 端 需要 与 其 通信 ， 那 么 保留 ClusterIP 似 乎 也 是 很 有 必要 的 。 


下 面 的 配置 文件 中 定义 了 Service 资 源 tomcat-svc， 它 通过 标签 选择 
厂 将 相关 的 Pod 对 象 归 于 一 组 ， 并 通过 80/TCP 端 口 又 露 Pod 对 象 的 
8080/TCP 端 口 。 如 果 需 要 暴露 容器 的 8009/TCP 端 口 ， 那 么 只 需要 将 其 
以 类 似 的 格式 配置 于 列表 中 即 可 : 


apiVersion: v1 
kind: Service 
metadata: 
name: tomcat-svc 
namespace: testing 
lJabels: 
app: tomcat-svc 
spec: 
selector: 
app: tomcat 
ports: 
- name: http 
port: 80 
targetPort: 8080 
protocol: TCP 


运行 资源 创建 命令 完成 Service 资 源 的 创建 : 


~]$ kubect1 apply -f tomcat-svc.yaml 


接着 运行 命令 以 确认 其 成 功 完成 : 


~]$ kubect1 get svc tomcat-svc -n testing 
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE 
tomcat-svc ClusterIP 10.108.72.237 <none> 80/TCP 8s 


6.7.4 创建 Ingress 资 源 


通过 Ingress 资 源 的 FQDN 主 机 名 或 URL 路 径 等 


有 用 户 的 访问 请 求 能 够 匹配 到 其 


类 型 发 布 的 服务 ， 全 
.Spec.rules.host 字 段 定 义 的 主机 时 才能 


被 相应 的 规则 处 理 。 如 果 要 明确 匹配 用 户 的 处 理 请 求 ， 比如 希 望 将 屠 
些 发 往 tomcat.ilinux.io 主 机 的 所 有 请 求 代理 至 tomcat-svc 资 源 的 后 端 


Pod， 则 可 以 使 用 如 下 命令 


apiVersion: extenSsions/Vv1betal 
kind: Ingress 
metadata: 
name: tomcat 
namespace: testing 
annotations: 
kubernetes.io/ingress.class: 
spec: 
rules: 
- host: tomcat.ilinux.io 
http: 
paths : 
path : 
backend 
serviceName: tomcat-svc 
servicePort: 80 


行 资源 创建 命令 


配置 文件 中 的 内 容 : 


"nginx" 


完成 Service 资 源 的 创建 


~]$ kubect1 apply -f tomcat-ingress.yaml 


而 后 通过 诗 细 信 言 忌 人 确认 其 创 
应 的 tomcat-svc 资 源 上 : 


~]$ kubectl describe ingresses 
Name: tomcat 
Namespace: testing 
Address: 
Default backend: 
Rules: 

Host Path 


tomcat .ilinux.io 


建成 功 完 成 ， 并 且 已 经 正确 关联 到 相 


-n testing 


default-http-backend:80 (<none>) 


Backends 


tomcat-svc:80 (<none>) 


Annotations: 
Events: 


Type Reason Age From Message 


接 下 来 即 可 通过 Ingress 控 制 右 的 前 端 Service 资 源 的 NodePort 来 访问 
此 服务 ， 在 6.6.4 节 中 ， 此 Service 资 源 的 ClusterIP 被 明确 定义 为 
10.99.99.99， 并 以 节点 端口 30080 映 射 Imgress 控 制 器 的 80 端 口 。 因 此 ， 
这 里 使 用 Ingress 中 定义 的 主机 名 tomcat.ilinux.io: 30080 即 可 访问 tomcat 
应 用 ， 图 6-16 所 示 的 是 访问 页 面 的 效果 。 当 然 ， 实 践 中 ， 其 前 端 应 该 
有 一 个 外 部 的 负载 均衡 设备 接收 并 调度 此 类 请 求 。 


€ 3 GC On tomcatikubemetes,io:30080 中 
Home Documentation Configuration Examples Wiki Mailing Lists Find Heip 
Apache Tomcat/8.0.50 Af APACHE Re 


if you're seeing this, you've successfully installed Tomcat. 
Congratulations! 


™ Recommended Reading: Server Status | 
ManagerApp 
ClusteringlSession Replication HOW-TO 2 


图 6-16 ”访问 Ingress 资 源 代理 的 tomcat 应 用 


不 过 ， 用 户 对 tomcat.ilinux.io 主 机 之 外 的 地 址 发 起 的 被 此 Ingress 规 
则 匹配 到 的 请 求 将 发 往 Ingress 控 制 絮 的 默认 的 后 端 ， 即 default-http- 
backend， 它 通常 只 能 返回 一 个 404 提 示 信 息 。 用 户 也 可 按 需 自 定义 默 
认 后 端 ， 例 如 ， 如 下 面 的 配置 文件 片断 所 示 ， 它 通过 .spec.backend 定 义 
了 所 有 无 法 由 此 Ingress 匹 配 的 访问 请 求 都 由 相应 的 后 端 default-svc 这 个 
Service 资 源 来 处 理 : 


spec: 
backend: 
serviceName: default-svc 
servicePort: 80 


6.7.5 配置 TLS Ingress 资 源 


一 般 来 说 ， 如 果 有 基于 HTTPS 通 信 的 需求 ， 那 么 它 应 该 由 外 部 的 
负载 均衡 器 (external-LB) 予以 实现 ， 并 在 SSL 会 话 御 载 后 将 访问 请 
求 转发 到 Ingress 控 制 器 。 不 过 ， 如 果 外 部 负载 均衡 右 工 作 于 传输 层 而 
不 是 工作 于 应 用 层 的 反问 代理 服务 器 ， 或 者 存在 直接 通过 Ingress 控 制 
右 接 收 客户 端 请 求 的 需求 ， 又 期 望 它们 能 够 提供 HTTPS 服 务 时 ， 束 应 
该 配置 TLS 类 型 的 Ingress 资 源 。 


将 此 类 服务 公开 发 布 到 互联 网 时 ，HTTPS 服 务 用 到 的 证 书 应 由 公 
信 CA 签 署 并 颁发 ， 用 户 遵 循 其 相应 流程 准备 好 相关 的 数字 证 书 即 可 。 
如 果 出 于 测试 或 内 部 使 用 之 目的 ， 那 么 也 可 以 选择 自制 私有 证 书 。 
openssl 工 具 程 序 是 用 于 生成 自 签证 书 的 常用 工具 ， 这 里 使 用 它 生 成 用 
于 测试 的 私 钥 和 自 签证 书 : 


~]$ openssl genrsa -out tls.key 2048 
~]$ openssl req -new -x509 -key tls.key -out tls.crt \ 
-Subj /C=CN/ST=Beijing/L=Beijing/0=DevOps/CN=tomcat.ilinux.io -days 3650 


SS 

© 注意 ”TLS Secret 中 包含 的 证 书 必须 以 tls.crt 作 为 其 键 名 ， 私 
钥 文 件 必须 以 tls.key 为 键 名 ， 因 此 上 面 生成 的 私 钥 文 件 和 证 书 文件 名 
0 形式 ， 以 便于 后 面 创 建 Secret 对 象 时 直接 作为 键 名 引 


在 mgress 探 制 狠 上 配置 HTTPS 主 机 时 ， 不 能 直接 使 用 私 铀 和 证 书 
文件 ， 而 是 要 使 用 Secret 资 源 对 象 来 传递 相关 的 数据 。 所 以 ， 接 下 来 要 
根据 私 铀 和 证 书生 成 用 于 配置 TLS Ingress 的 Secret 资 源 ， 在 创建 Ingress 
规则 时 由 其 将 用 到 的 Secret 资 源 中 的 信息 注入 Ingress 控 制 器 的 Pod 对 象 
中 ， 用 于 为 配置 的 HTTPS 虚 拟 主机 提供 相应 的 私 铀 和 证 书 。 下 面 的 命 
令 会 创建 一 个 TLS 类 型 名 为 tomcat-ingress-secret 的 Secret 资 源 : 


~]$ kubect1l create Secret tls tomcat-ingress-secret --cert=tls,crt --key=tls. 
key -n testing 


可 使 用 下 面 的 命令 确认 Secrets 资 源 tomcat-ingress-secret 创 建成 功 完 
成 : 


~]$ kubectl1 get secrets tomcat-ingress-secret -n testing 
NAME TYPE DATA AGE 
tomcat-ingress-secret kubernetes.io/tls 2 20s 


而 后 去 定义 创建 TLS 类 型 Ingress 资 源 的 配置 清单 。 下 面 的 配置 清 
单 通过 spec.rules 定 义 了 一 组 转发 规则 ， 并 通过 .spec.tls 将 此 主机 定义 为 
了 HTTPS 类 型 的 虚拟 主机 ， 用 到 的 私 铀 和 证 书信 息 则 来 和 目 于 Secrets 资 


源 tomcat-ingress-secret: 


apiVersion: extensions/vibeta1 
kind: Ingress 
metadata: 
name: tomcat-ingress-tls 
annotations: 
kubernetes.io/ingress.class: "nginx" 
spec: 
tls: 
- hosts: 
- tomcat.ilinux.io 
secretName: tomcat-ingress-secret 
rules: 


- host: tomcat.ilinux.io 


serviceName: tomcat-svc 
servicePort: 80 


了 资源 创建 命令 完成 Service 资 源 的 创建 : 


~]$ kubect1 apply -f tomcat-ingress-tls.yaml 


而 后 通过 详细 信息 确认 其 创建 成 功 完成 ， 且 已 经 正确 关联 到 相应 


的 tomcat-svc 资 源 : 


~]$ kubectl1 describe ingress tomcat-ingress-tls -n testing 


Name : tomcat-ingress-tls 
Namespace: testing 
Address: 


Default backend: default-http-backend:80 (<none>) 


TLS: 

tomcat-ingress-secret terminates tomcat.ilinux.io 
Rules: 

Host Path Backends 

tomcat .ilinux.io 
/ tomcat-svc:80 (<none>) 


Annotations: 
Events: 
Type Reason ge From Message 


Ni CREATE 31s nginx-ingress-controller Ingress testing/tomcat-ingress- 
tls 


接 下 来 即 可 通过 Ingress 控 制 器 的 前 前 端 Service 资 源 的 NodePort 来 访 
问 此 服务 ， 在 6.6.4 节 中 ， 此 Service 资 源 以 世 点 端 口 30443 映 射 控 制 器 | 
443 端 口 。 因 此 ， 这 里 使 用 Ingress 中 定义 的 主机 名 tomcat.ilinux.io: 
30443 即 可 访问 tomcat 必 用 ， 其 访问 到 的 页 面 效 果 类 似 于 图 6-16 中 的 内 
容 。 另 外 ， 也 可 以 使 用 cunl 进 行 访 问 测 试 ， 只 要 对 应 的 主机 能 够 正确 
解析 tomcat.ilinux.io 主 机 名 即 可 ， 例 如 ， 下 面 的 测试 命令 及 其 输出 表 
明 ，TLS 类 型 的 Ingress 已 然 配 置 成 功 : 


~]# curl -k -v https://tomcat.ilinux.io:30443/ 

* About to connect() to tomcat.ilinux.io port 30443 (#0) 

Trying 172.16.0.66.,.. 

* Server certificate: 

subject: CN=tomcat.ilinux.io,0=DevOps,L=Beijing,ST=Beijing,C=CN 
加 start date: Aug 23 07:05:31 2018 GMT 

二 expire date: Aug 20 07:05:31 2028 GMT 

中 common name: tomcat.ilinux.io 

水 issuer: CN=tomcat.ilinux.1io,0=DevOps,L=Beijing,ST=Beijing,C=CN 
> GET / HTTP/1.1 

< HTTP/1.1 200 OK 

< Server: nginx/1.13.9 

< Date: Thu, 23 Aug 2018 07:37:40 GMT 


到 此 为 止 ， 实 践 配置 目标 已 经 全 部 达成 。 需 要 再 次 提醒 的 是 ， 在 
实际 使 用 中 ， 在 集群 之 外 应 该 存在 一 个 用 于 调度 用 户 请 求 至 各 和 点 上 
Ingress 控 制 絮 相关 的 NodePort 的 负载 均衡 絮 。 如 果 不 具 有 LBaaS 的 使 用 
条 件 ， 用 户 也 可 以 基于 Nginx、Haproxy、LVS 等 手动 构建 ， 并 通过 
Keepalived 等 解决 方案 实现 其 服务 的 高 可 用 配置 。 


6.8 本章 小 结 
本 章 重 点 讲解 了 Kubernetes 的 Service 资 源 及 其 发 布 方式 ， 具 体 如 


[© 


'Service 资 源 通过 标签 选择 器 为 一 组 Pod 资 源 创建 一 个 统一 的 访问 
入 口 ， 其 可 将 客户 端 请 求 代理 调度 至 后 端的 Pod 资 源 。 


Service 资 源 是 四 层 调 度 机 制 ， 默 认 调 度 算法 为 随机 调度 。 


“Service 的 实现 模式 有 三 种 : userspace、iptables 和 ipvs。 


:Service 共 用 四 种 类 型 ，ClusterIP、NodePort、LoadBalancer 和 
ExternalName， 它 们 用 于 发 布 服务 。 


.Headless service 是 一 种 特殊 的 Service 资 源 ， 可 用 于 Pod 发 现 。 


.Ingress 资 源 是 发 布 Service 资 源 的 另 一 种 方式 ， 它 需要 结合 Ingress 
控制 器 才能 正常 工作 。 


.Ingress Controller 的 实现 方式 除了 Nginx 之 外 ， 还 有 Envoy、 
HAProxy、Traefik 等 。 


第 7 章 ”存储 卷 与 数据 持久 化 


应 用 程序 在 处 理 请 求 时 ， 可 根据 其 对 当前 请 求 的 处 理 是 否 受 影 啊 
于 此 前 的 请 求 ， 将 应 用 划分 为 有 状态 应 用 和 无 状态 应 用 两 种 。 微 服务 
体系 中 ， 各 种 应 用 均 补 拆 分 成 了 从 多 微服 务 或 更 小 的 应 用 模块 ， 因 此 
往往 会 存在 为 数 不 少 的 有 状态 应 用 ， 当 然 ， 也 会 存在 数量 可 观 的 无 状 
态 应 用 。 而 对 于 有 状态 应 用 来 说 ， 数 据 持 人 久 化 几乎 是 必然 之 需 。 


Kubernetes 提 供 的 存储 卷 《Volume) 属于 Pod 资 源 级 别 ， 共 享 于 
Pod 内 的 所 有 容器 ， 可 用 于 在 容 恬 的 文件 系统 之 外 存储 应 用 程序 的 相 
关 数 据 ， 甚 至 还 可 独立 于 Pod 的 生命 周期 之 外 实现 数据 持久 化 。 本 章 
主要 介绍 Kubernetes 系 统 之 上 的 主流 存储 卷 类 型 及 其 应 用 。 


7.1 和 存储 知 概 述 


Pod 本 身 具有 生命 周期 ， 故 其 内 部 运行 的 容 右 及 其 相关 数据 目 喘 
均 无 法 持久 存在 。Docker 文 持 配 置 容器 使 用 存储 卷 将 数据 持久 存储 于 
容 需 目 身 文件 系统 之 外 的 存储 空间 中 ， 写 们 可 以 是 斑点 文件 系统 或 网 
络 文件 系统 之 上 的 存储 空间 。 相 应 地 ，Kubernetes 也 文 持 类 似 的 存储 
卷 功能， 不过， 其 存储 卷 是 与 Pod 和 货源 绑 定 而 非 容 右 。 简 单 来 说 ， 存 
储 卷 是 定义 在 Pod 资 源 之 上 、 可 被 其 内 部 的 所 有 容器 持 载 的 共享 上 
录 ， 它 关联 至 时 外 部 的 存储 设备 之 上 的 存储 空间 ， 从 而 独立 于 容 右 目 
身 的 文件 系统 ， 而 数据 是 否 具有 持久 能 力 则 取决 于 存储 卷 目 身 是 否 文 
持 持 久 机 制 。Pod、 容器 与 存储 卷 的 关系 如 图 7- TA 


Pod 


Ic ontainer2 2 
| 


全 9 


volumeMounts | 


volumes 


C ontainer 1 


2 一 一 一 


图 7-1 Pod、 容器 与 存储 关 


7.1.1 ”Kubemetes 支 持 的 存储 卷 类 型 


Kubernetes 支 持 非 常 丰富 的 存储 卷 类 型 ， 包 括 本 地 存储 (节点 ) 

和 网 络 存储 系统 中 的 诸多 存储 机 制 ， 甚 至 还 支持 Secret 和 ConfigMap 这 
样 的 特殊 存储 资源 。 对 于 Pod 来 说 ， 卷 类 型 主要 是 为 关联 相关 的 存储 
系统 时 提供 相关 的 配置 参数 ， 例 如 ， 关 联 节点 本 地 的 存储 目录 与 关联 
GlusterFS 存 储 系统 所 需要 的 配置 参数 差异 巨大 ， 因 此 指定 存储 卷 类 型 
时 也 就 限定 了 其 关联 到 的 后 端 存储 设备 。 目 前 ，Kubernetes 支 持 的 存 
储 卷 包含 以 下 这 些 类 型 。 


-emptyDir 
:hostPath 

‘nfs 

‘fc 

"iscsi 

“flocker 

‘Glusterfs 

‘rbd 

:cephfs 

‘cinder 
‘awsElasticBlockStore 
‘gcePersistentDisk 
“azureDisk 


“azureFile 


'gitRepo 
:downwardAPI 
‘ConfigMap 

“secret 

‘projected 

‘name 
‘persistentVolumeClaim 
:downwardAPI 
‘vsphereVolume 
‘quobyte 
‘portworxVolume 
‘photonPersistentDisk 
'ScaleIO 

‘flexVolume 
“storageOS 


:local 


上 述 类 型 中 ，emptyDir 与 hostPath 属 于 节点 级 别 的 卷 类 型 ， 
emptyDir 的 生命 周期 与 Pod 资 源 相 同 ， 而 使 用 了 hostPath 卷 的 Pod 一 旦 被 
重新 调度 至 其 他 方 点 ， 那 么 它 将 无 法 再 使 用 此 前 的 数据 。 因 此 ， 这 两 
种 类 型 都 不 具有 持久 性 。 要 想 使 用 持久 类 型 的 存储 卷 ， 就 得 使 用 网 络 
存储 系统 ， 如 NEFS、Ceph、GlusterFS 等 ， 或 者 云端 存储 ， 如 


gcePersistentDisk、awsElasticBlockStore 等 。 


然而 ， 网 络 存 储 系统 通常 都 不 太 容 易 使 用 ， 有 的 甚至 很 复杂 ， 以 
至 于 对 大 多 数 用 户 来 说 它 是 一 个 难以 逾越 的 障碍 。Kubernetes 为 此 专 
门 设计 了 一 种 集群 级 别 的 资源 PersistentVolume (简称 PV) ， 它 借 由 管 
理 员 配 置 存 储 系 统 ， 而 后 由 用 户 通 过 “persistentVolumeClaim”( 简 称 
PVC) 存储 卷 直接 申请 使 用 的 机 制 大 大 人 简化 了 终端 存储 用 户 的 配置 过 
程 ， 有 效 降 低 了 使 用 难度 。 


再 者 ，Secret 和 ConfigMap 算 得 上 是 两 种 特殊 的 卷 类 型 。 


1) Secret 用 于 癌 Pod 传 递 敏 感 信息 ， 如 密码 、 私 钥 、 证 书 文件 
等 ， 这 些 信 息 如 果 和 直接 定义 在 镜像 中 很 容易 导致 泄露 ， 有 了 Secret 资 
源 ， 用 户 可 以 将 这 些 信息 存储 于 集群 中 而 后 由 Pod 进 行 挂 载 ， 从 而 实 
现 将 敏感 数据 与 系统 解 耦 。 


2) ConfigMap 资 源 则 用 于 向 Pod 注 入 非 敏 感 数 据 ， 使 用 时 ， 用 户 
将 数据 直接 存储 于 ConfigMap 对 象 中 ， 而 后 直接 在 Pod 中 使 用 
I 它 可 以 帮助 实现 容 需 配置 文件 集中 化 定义 
[管理 。 


另外 ，Kubernetes 目 1.9 版 本 起 对 存储 的 文 持 做 了 进一步 的 增强 ， 
引入 了 容器 存储 接口 (Container Storage Interface，CSI) 的 一 套 alpha 
实现 版 本 ， 其 能 够 将 插件 的 安装 流程 简化 至 与 创建 Pod 相 当 ， 并 人 允许 
第 三 方 存储 供应 商 在 无 须 修改 Kubernetes 代 码 库 的 前 提 下 提供 自己 的 
解决 方案 。 因 此 ，Kubernetes 系 统 文 持 的 卷 存 储 机 制 必 将 进一步 增 
强 。 


7.1.2 存储 苍 的 使 用 方式 


在 Pod 中 定义 使 用 存储 卷 的 配置 由 两 部 分 组 成 : 一 是 通 
过 .spec.volumes 字 段 定 义 在 Pod 之 上 的 存储 卷 列表 ， 其 文 持 使 用 多 种 不 
同类 型 的 存储 卷 且 配置 参数 差别 很 大 ;， 男 一 个 是 通 
过 .spec.containers.volumeMounts 字 段 在 容器 上 定义 的 存储 卷 挂 载 列 
表 ， 它 只 能 挂 载 当 前 Pod 资 源 中 定义 的 具体 存储 卷 ， 当 然 ， 也 可 以 不 
挂 载 任何 存储 卷 。 如 图 7-1 所 示 。 


在 Pod 级 别 定义 存储 卷 时 ，.spec.volumes 字 段 的 值 是 对 象 列 表格 
式 ， 每 个 对 象 为 一 个 存储 卷 的 定义 ， 它 由 存储 卷 名 称 
(.spec.volumes.name<String>) 或 存储 卷 对 象 
(.spec.volumes.VOL_TYPE<Object>) 组 成 ， 其 中 VOL_TYPE 是 使 用 
的 存储 卷 类 型 名 称 ， 它 的 内 内 字 段 随 类 型 的 不 同 而 不 同 。 下 面 的 资源 
清单 片段 定义 了 由 两 个 存储 卷 组 成 的 卷 列表 ， 一 个 是 emptyDir 类 型 ， 


一 个 是 gitRepo 类 型 : 


spec: 


volumes: 
- name: logdata 
emptyDir: {} 
- name: example 
gitRepo: 

repository: https://github.com/iKubernetes/k8s_book.git 
revision: master 
directory: . 


定义 好 的 存储 卷 可 由 当前 Pod 资 源 内 的 各 容 强 进行 挂 载 。 事 实 
上 ， 也 只 有 多 个 容 句 挂 载 同一 个 存储 卷 时 ,“ 共 至 ” 才 有 了 具体 的 意 
义 。 当 Pod 中 只 有 一 个 容 各 时， 使 用 存储 卷 的 目的 通常 在 于 数据 持久 
化 。.spec.containers.volumeMounts 字 段 的 值 也 是 对 象 列 表格 式 ， 由 一 
到 多 个 存储 卷 挂 载 定义 组 成 。 无 论 何 种 类 型 的 存储 卷 ， 它 们 的 挂 载 格 
下 面 的 代码 段 是 在 容 笑 中 定义 挂 载 卷 时 的 通用 
语 # 式 \: 


spec: 


containers: 


- _ name: <String> 


VolLumeMounts : 

- name <string> -required- 
mountPath <string> -required- 
readonly <boolean> 
SubPath <string> 
mountPropagation <string> 


其 中 各 字段 的 意义 及 使 用 要 求 具体 如 下 。 
‘name<string>: 指定 要 挂 载 的 存储 的 名 称 ， 必 选 字段 。 


mountPath<string>: 挂 载 点 路 径 ， 容 器 文件 系统 上 的 路 径 ， 必 选 
字段 。 


:readOnly<boolean>: 是 否 挂 载 为 只 读 卷 。 


“subPath<string>: 挂 载 存储 卷 时 使 用 的 子路 径 ， 即 在 mountPath 指 
定 的 路 径 下 使 用 一 个 子路 径 作 为 其 挂 载 点 。 


下 面 古 一 个 挂 载 示 例 ， 容 絮 myapp 将 logdata 存 储 卷 挂 载 
于 /var/log/myapp， 将 example 挂 载 到 /webdata/example 目 录 : 


spec: 
containers: 
- name: myapp 
image: ikubernetes/myapp:v7 
volumeMounts: 
- name: logdata 
mountPath: /var/log/myapp/ 
- name: example 
mountPath: /webdata/example/ 


存储 卷 的 定义 基本 相似 ， 因 此 本 章 后 面 的 篇 幅 将 重点 放 在 介绍 主 
尝 存 储 疮 类 型 的 配置 及 使 用 方式 ， 而 且 出 于 保持 示例 简洁 及 节约 篇 幅 
的 目的 ， 本 草 的 示例 主要 以 目 主 式 Pod 资 源 为 主 。 


7.2 ”临时 存储 卷 


Kubernetes 文 持 存 储 卷 类 型 中 ，emptyDir 存 储 卷 的 生命 周期 与 其 所 
属 的 Pod 对 象 相 同 ， 它 无 法 脱离 Pod 对 象 的 生命 周期 提供 数据 存储 功 
能 ， 因 此 emptyDir 通 常 仅 用 于 数据 缓存 或 临时 存储 。 不 过 ， 基 于 
emptyDir 构 建 的 gitRepo 存 储 卷 可 以 在 Pod 对 象 的 生命 周期 起 始 时 从 相 
应 的 Git 仓 库 中 复制 相应 的 数据 文件 到 底层 的 emptyDir 中 ， 从 而 使 得 它 
具有 了 一 定 意 义 上 的 持久 性 。 


7.2.1 emptyDir 存 储 卷 


emptyDir 存 储 卷 是 Pod 对 象 生 命 周 期 中 的 一 个 临时 目录 ， 类 似 于 
Docker 上 的 “docker 挂 载 卷 >， 在 Pod 对 象 司 动 时 即 被 创建 ， 而 在 Pod 对 
象 被 移 除 时 会 被 一 并 删除 。 不 具有 持久 能 力 的 emptyDir 存 储 卷 只 能 用 
于 某 些 特殊 场景 中 ， 例 如 ， 同 一 Pod 内 的 多 个 容器 间 文 件 的 共享 ， 或 
者 作为 容 絮 数据 的 临时 存储 目录 用 于 数据 缓存 系统 等 。 


emptyDir 存 储 卷 则 定义 于 .spec.volumes.emptyDir 舱 套 字段 中 ， 可 
用 字段 主要 包含 两 个 ， 具 体 如 下 。 


-medium: 此 目录 所 在 的 存储 介质 的 类 型 ， 可 取 值 
为 “default” 或 *Memory”， 默 认为 default， 表 示 使 用 点 的 默认 存储 介 
质 ;“Memory” 表 示 使 用 基于 RAM 的 临时 文件 系统 tmpfs， 空 间 受 限于 
内 存 ， 但 性 能 非常 好 ， 通 常用 于 为 容器 中 的 应 用 提供 缓存 空间 。 


sizeLimit: 当前 存储 卷 的 空间 限额 ， 默 认 值 为 nil， 表 示 不 限制 ; 
不 过 ， 在 medium 字 上 段 值 为 “Memory” 时 建议 务必 定义 此 限额 。 


下 面 是 一 个 使 用 了 emptyDir 存 储 卷 的 简单 示例 ， 它 保存 于 vol- 
emptydiryaml 配 置 文件 中 : 


apiVersion: v1 
kind: Pod 
metadata: 
name: vol-emptydir-pod 
spec: 
volumes: 
- name: html 
emptyDir: {} 
containers: 
- name: nginx 
image: nginx:1.12-alpine 
volumeMounts: 
- name: html 
mountPath: /usr/share/nginx/html 
- name: pagegen 
image: alpine 
volumeMounts: 
- name: html 
mountPath: /html 
command: ["/bin/sh", "-c"] 
args: 
- while true; do 


echo $(hostname) $(date) >> /html/index.html; 
Sleep 10; 
done 


上 面 的 示例 中 定义 的 存储 卷 名 称 为 htm1， 挂 载 于 容 硕 nginx 
的 /usr/share/nginx/html 目 录 ， 以 及 容器 pagegen 的 /html 目 录 。 容 器 
pagegen 每 阳 10 秒 同 存 储 卷 上 的 index.html 文 件 中 追加 一 行 信息 ， 而 容 
怖 nginx 中 的 nginxj 进 程 则 以 其 为 站 点 主页 ， 如 图 7-2 所 示 。 


Pr-————"—""—— 


Container:pagegen 


图 7 2 存储 着 使 用 示意 图 


Pod 资 源 的 详细 信息 中 会 显示 存储 卷 的 相关 状态 ， 包 括 其 是 否 创 
建成 功 (在 Events 字 段 中 输出 ) 、 相 关 的 类 型 及 参数 〈 在 Volumes 字 段 
中 输出 ) 以 及 容器 中 的 挂 载 状 态 等 信息 (在 Containers 字 段 中 输出 ) 。 
如 下 面 的 命令 结果 所 示 : 


~]$ kubectl1 describe pods vol-emptydir-pod 
Name: vol-emptydir-pod 


nginx: 


Mounts: 


/usr/share/nginx/html from html] (rw) 
pagegen: 
Mounts: 
/html from html] (rw) 


Volumes: 
html: 
Type: EmptyDir (a temporary directory that shares a pod's lifetime) 
Medium: 


Type Reason Age From Message 


to node03.ilinux.io 
Normal SuccessfulMountVolume 10s kubelet, node03.ilinux.io MountVolume. 
SetUp succeeded for volume "htmil" 


而 后 ， 可 以 为 其 创建 Service 资 源 并 进行 访问 测试 ， 或 者 在 集群 中 
直接 对 Pod 的 地 址 发 起 访问 请 求 ， 以 测试 两 个 容 絮 通过 emptyDir 卷 共 诗 
数据 的 结果 状态 : 


~]$ curl 10.1.3.106 
vol-emptydir Wed Mar 7 01:10:56 UTC 2018 


作为 边 车 (sidecar) 的 容器 paggen， 其 每 隔 10 秒 生成 一 行 信息 追 
加 到 存储 人 卷 上 的 index.html 文 件 中 ， 因 此 ， 通 过 主 容器 nginx 的 应 用 访 
问 到 的 内 容 也 会 处 于 不 集 的 变动 中 。 男 外 ，emptyDir 存 储 卷 也 可 以 基 
于 RAM 创 建 tmpfs 文 件 系 统 的 存储 卷 ， 党 用 于 为 容 右 的 应 用 提供 高 性 
能 缓存 ， 下 面 是 一 个 配置 示例 : 


vOolumes: 
- Name: cache 
emptyDir: 
medium: Memory 


emptyDir 卷 简单 易 用 ， 但 仅 能 用 于 临时 存储 。 另 外 还 存在 一 些 类 
型 的 存储 卷 建构 在 emptyDir 之 上 ， 并 额外 提供 了 它 所 没有 的 功能 ， 例 
如 ， 将 于 7.2.2 节 介绍 的 gitRepo 存 储 卷 。 


7.2.2 gitRepo 存 储 卷 


gitRepo 存 储 符 可 以 看 作 是 emptyDir 人 存储 郑 的 一 种 实际 应 用 ， 使 用 
该 存储 卷 的 Pod 资 源 可 以 通过 挂 载 日 录 访 问 指 定 的 代码 仓库 中 的 数 
据 。 。 使 用 gitRepo 存 储 卷 的 Pod 资 源 各 在 创建 时 ， 会 首先 创建 一 个 空 目录 
(emptyDir) 并 克隆 (clone) 一 份 指定 的 Git 仓 库 中 的 数据 至 该 目录 ， 
而 后 再 创建 容 右 并 挂 载 该 存储 卷 。 


“定义 gitRepo 关 型 的 存储 若林 ， 其 可 崩 套 使 用 的 字段 具体 包含 如 下 


:repository<string> : Git 仓 库 的 URL ， 必 选 字段 。 
-directory<string> : 目标 目 永 名称 ， 名 称 中 不 能 包含 “.." 字 
符 ;“.” 表 示 将 仓库 中 的 数据 直接 复制 到 卷 目 录 中 ， 否 则 ， 即 为 复制 到 
卷 目 录 中 以 用 户 指 定 的 字符 串 为 名 称 的 子 目 录 中 。 


:revision<string> : 特定 revision 的 提交 哈 希 码 。 


O 注意 ”使 用 gitRepo 存 储 卷 的 Pod 资 源 运 行 的 工作 节点 上 必须 
安装 有 Git 程 序 ， 否 则 克隆 仓库 的 操作 将 无 从 完成 。 另 外 ， 自 
Kubernetes 1.12 起 ，gitRepo 存 储 卷 已 经 被 废弃 。 


下 面 示例 (vol-gitrepo.yaml 配 置 文件 ) 中 的 Pod 资 源 在 创建 时 ， 首 
移 会 创建 一 个 空 目 孙 ， 将 指定 的 Git 仓 库 
https://github.com/iKubernetes/k8s_book.git 中 的 数据 复制 一 份 直接 保存 
于 此 目录 中 ， 而 后 将 此 目录 创建 为 存储 卷 html， 最 后 由 容 右 Nginx 将 此 
存储 卷 挂 载 于 /usr/share/nginx/html 目 好 上 : 


apiVersion: v1 
kind: Pod 
metadata: 
name: vol-gitrepo-pod 
spec: 
containers: 
- name: nginx 
image: nginx:1.12-alpine 
volumeMounts: 


- name: html 
mountPath: /usr/share/nginx/html 


volumes: 
- name: html 
gitRepo: 
repository: https://github.com/ikKubernetes/k8s_book.git 


directory: . 
revision: "master" 


访问 此 Pod 资 源 中 的 Nginx 服 务 即 可 看 到 其 来 自 于 Git 仓 库 中 的 页 面 
资源 。 不 过 ， gitRepo 存 储 卷 在 其 创建 完成 后 不 会 再 与 指 定 的 仓库 执行 
同步 操作 ， 这 就 意味 着 在 Pod 资 源 运行 期 间 ， 如 果 仓 库 中 的 数据 发 生 
了 变化 ， 那么 gitRepo 存 储 卷 不 : ` 会 同步 到 这 些 内 容 。 当 然 ， 此 时 可 以 为 
Pod 资 源 创 建 一 个 专用 的 边 车 容 絮 用 于 执行 此 类 的 同步 操作 ， 尤 其 是 
数据 来 源 于 私有 仓库 时 ， 通 过 边 车 容 需 完成 其 复制 瓯 更 为 必要 。 


gitRepo 存 储 卷 建构 于 emptyDir 存 储 卷 之 上 ， 它 的 生命 周期 与 隶属 
的 Pod 对 和 象 相 同 ， 因 此 使 用 时 不 建议 在 此 类 存储 卷 中 保存 由 容器 生成 
的 重要 数据 。 另 外 ， 目 Kubernetes 1.12 版 起 ，gitRepo 存 储 卷 已 经 被 废 
弃 ， 所 以 在 之 后 的 版 本 中 车 要 使 用 它 配置 Pod 对 象 ， 建 议 读者 借助 初 
化 容器 (InitContainer) 将 仓库 中 的 数据 复制 到 emptyDir 存 储 卷 上 ， 


并 在 主 容 右 中 使 用 此 存储 卷 。 


7.3 “万 点 存储 卷 hostPath 


hostPath 类 型 的 存储 卷 是 指 将 工作 节点 上 某 文件 系统 的 目 孙 或 文件 
挂 载 于 Pod 中 的 一 种 存储 卷 ， 它 可 独立 于 Pod 资 源 的 生命 周期 ， 因 而 具 
有 持久 性 。 但 它 是 工作 市 点 本 地 的 存储 空间 ， 仪 适用 于 特定 情况 下 的 
存储 耸 使 用 需求 ， 例 如 ， 将 工作 节点 上 的 文件 系统 关联 为 Pod 的 存储 
卷 ， 从 而 使 得 容器 访问 节点 文件 系统 上 的 数据 。 这 一 点 在 运行 有 管理 
任务 的 系统 级 Pod 资 源 需 要 访问 方 点 上 的 文件 时 尤为 有 用 。 

配置 hostPath 存 储 卷 的 和 藤 套 字段 共有 两 个 : 一 个 是 用 于 指定 工作 节 
点 上 的 目 孙 路 径 的 必 选 字段 path;， 另 一 个 是 指定 存储 着 类 型 的 type， 它 
文 持 使 用 的 眷 类 型 包含 如 下 几 种 。 


DirectoryOrCreate: 指定 的 路 径 不 存 时 目 动 将 其 创建 为 权限 是 
0755 的 空 目 未 ， 属 主 属 组 均 为 kupelet 。 


.Directory: 必须 存在 的 目 孙 路 径 。 


:FileOrCreate: 指定 的 路 径 不 存 时 目 动 将 其 创建 为 权限 是 0644 的 罕 
文件 ， 属 主 和 属 组 同 是 kubelet 。 


:File 必须 存在 的 文件 路 径 。 

“Socket: 必须 存在 的 Socket 文 件 路 径 。 
.CharDevice: 必须 存在 的 字符 设备 文件 路 径 。 
.BlockDevice: 必须 存在 的 块 设备 文件 路 径 。 

下 面 是 定义 在 vol-hostpath.yaml 配 置 文 件 中 的 Pod 资 源 ， 它 运行 着 


日 志 收 集 代 理应 用 包 ebeat， 负 责 收 集 工 作 贡 点 及 容器 相关 的 日 志 信 息 
发 往 Redis 服 务 絮 ， 它 使 用 了 三 个 hostPath 类 型 的 存储 卷 : 


apiVersion: v1 
kind: Pod 
metadata: 
name: vol-hostpath-pod 
spec: 
containers: 


- name: filebeat 
image: ikubernetes/filebeat:5.6.7-alpine 
env: 
- name: REDIS_ HOST 
value: redis.ilinux.io:6379 
- Name: LOG_LEVEL 
value: info 
volumeMounts: 
- name: varlog 
mountPath: /var/log 
- name: socket 
mountPath: /var/run/docker.sock 
- name: varlibdockercontainers 
mountPath: /var/lib/docker/containers 
readonly: true 
terminationGracePeriodSeconds: 30 
volumes: 
- name: varlog 
hostPath : 
path: /var/log 
- name: varlibdockercontainers 
hostPath : 
path: /var/lib/docker/containers 
- name: socket 
hostPath : 
path: /var/run/docker.sock 


这 类 Pod 资 源 通 销 受 探 于 daemonset 类 型 的 Pod 控 制 需 ， 它 运行 于 集 
群 中 的 每 个 工作 节点 之 上 ， 负 责 收 集 工 作 节 点 上 系统 级 的 相关 数据 ， 
因此 使 用 hostPath 存 储 卷 也 是 理 所 应 当 的 。 读 者 在 创建 上 述 Pod 资 源 
时 ， 如 果 有 可 用 的 Redis 服 务 器 ， 则 可 通过 环境 变量 REDIS_HOST 传 递 
给 Pod 资 源 ， 待 其 Ready 之 后 即 可 通过 Redis 服 务 器 查看 到 由 其 发 送 的 日 
志 信 筷 。 在 他 ebeat 的 应 用 架构 中 ， 这 些 日 志 信 息 会 发 往 Elasticsearch,， 
并 通过 Kibana 进 行 展示 。 


另外 ， 使 用 hostPath 存 储 卷 时 需要 注意 到 ， 不 同 世 点 上 的 文件 或 许 
并 不 完全 相同 ， 于 十 ， 那 些 要 来 事先 必须 存在 的 文件 或 目录 的 满足 状 
仿 也 可 能 会 有 所 不 同 ， 男 外 ， 基 于 资源 可 用 状态 的 调度 器 调度 Pod 
时 ，hostPath 资 源 的 可 用 性 状态 不 会 被 考虑 在 内 ， 再 者 ， 在 市 点 中 创建 
的 文件 或 目录 默认 仅 有 root 可 写 ， 帮 期 望 容 右 内 的 进程 拥有 写 权 限 ， 
则 要 么 将 它 运行 为 特权 容 右 ， 要 人 么 修改 市 点 上 目录 路 径 的 权限 。 


那些 并 非 执 行 系统 级 管理 任务 的 旦 不 受 控 于 Daemonset 控 制 絮 的 无 
状态 应 用 在 Pod 资 源 被 重新 调度 至 其 他 蔬 点 运行 时 ， 此 前 创建 的 文件 
或 目录 大 多 都 不 会 存在 。 因 此 ，hostPath 存 储 卷 虽然 能 持久 保存 数据 ， 
但 对 于 被 调度 辟 按 需 调 度 的 应 用 来 说 并 不 适用 ， 这 时 需要 用 到 的 是 独 
立 于 集群 和 点 的 持久 性 存储 卷 ， 即 网 络 存 储 卷 。 


7.4 网 络 存储 卷 


如 前 所 述 ，Kubernetes 拥 有 众多 类 型 的 用 于 适 配 专用 存储 系统 的 
网 络 存储 卷 。 这 类 存储 卷 包括 传统 的 NAS 或 SAN 设 备 (如 NFS、 
iSCSI、fc) 、 分 布 式 存储 (如 GlusterFS、RBD) 、 云 端 存储 (如 
gcePersistentDisk 、azureDisk、cinder 和 awsElasticBlockStore) 以 及 建构 
在 各 类 存储 系统 之 上 的 抽象 管理 层 (如 flocker、portworxVolume 和 


vsphereVolume) 等 。 


7.4.1 ”NFS 存储 卷 


NFS 即 网 络 文件 系统 (Network File System) ， 它 是 一 种 分 布 式 文 
件 系 统 协议 ， 最 初 是 由 Sun MicroSystems 公 司 开发 的 类 Unix 操 作 系 统 
之 上 的 一 款 经 典 的 网 络 存储 方案 ， 其 功能 旨 在 允许 客户 端 主机 可 以 像 
访问 本 地 存储 一 样 通过 网 络 访问 服务 硕 端 文件 。 作 为 一 种 由 内 核 原 生 
文 持 的 网 络 文件 系统 ， 具 有 Linux 系 统 使 用 经 验 的 读者 大 多 数 都 应 该 对 
NFS 有 一 定 的 使 用 经 验 。 


Kubernetes 的 NFS 存 储 卷 用 于 将 某 事 先 存在 的 NFS 服 务 右 上 导出 
(export) 的 存储 空间 挂 载 到 Pod 中 以 供 容 絮 使 用 。 与 emptyDir 不 同 的 
是 ，NFS 存 储 卷 在 Pod 对 象 终止 后 仅 是 被 外 载 而 非 删除 。 另 外 ，NFS 是 
文件 系统 级 共享 服务 ， 它 文 持 同时 存在 的 多 路 挂 载 请 求 。 定 义 NFS 存 
储 卷 时 ， 常 用 到 以 下 字段 。 


“server<string> : NFS 服 务 絮 的 IP 地 址 或 主机 名 ， 必 选 字 段 。 


:path<string> : NFS 服 务 器 导出 (共享 ) 的 文件 系统 路 径 ， 必 选 字 
段 。 


TeadOnly<boolean>: 是 否 以 只 读 方 式 挂 载 ， 默 认为 false。 


Redis (REmote DIctionary Server) 是 一 个 著名 的 高 性 能 key-value 
存储 系统 ， 应 用 非常 广泛 ， 将 其 部 署 运 行 于 Kubernetes 系 统 之 上 时 ， 
需要 持久 化 存储 卷 的 支持 。 下 面 是 简单 使 用 Redis 的 一 个 示例 : 


apiVersion: v1 
kind: Pod 
metadata: 
name: vol-nfs-pod 
lJabels: 
app: redis 
spec: 
containers: 
- name: redis 
image: redis:4-alpine 
ports: 
- containerPort: 6379 
name: redisport 
volumeMounts: 
- mountPath: /data 
name: redisdata 


VOLumes : 
- name: redisdata 
nfs: 
server: nfs.ilinux.io 
path: /data/redis 
readonly: false 


上 面 的 示例 定义 在 资源 配置 文件 vol-nfs.yaml 中 ， 其 中 的 Pod 资 源 
拥有 一 个 关联 至 NFS 服 务 器 nfs.ilinux.io 的 存储 卷 ，Redis 容 器 将 其 挂 载 
日 隶 上 ， 它 是 运行 于 容器 中 的 redis-server 数 据 的 持久 保存 位 


@ 提示 。 这 里 应 确保 事先 要 存在 一 个 名 为 nfs.ilinux.io 的 NFS 服 
务 絮 ， 其 输出 了 /data/redis 目 录 ， 并 授权 给 了 Kubernetes 集 群 中 的 节点 
访问 。 主 机 和 目录 都 可 以 按 需 要 进行 调整 。 


货源 创建 完成 后 ， 可 通过 其 命令 客户 端 redis-cli 创 建 测试 数据 ， 并 
手动 触发 其 同步 于 存储 系统 中 ， 下 面 加 粗 部 分 的 字体 为 要 执行 的 Redis 
i 


命令 : 


~]$ kubect1 exec -it vol-nfs-pod redis-cli 
127.0.0.1:6379> Set mykey "hello ilinux.io" 
OK 

127.0.0.1:6379> get mykey 

"hello ilinux.io" 

127.0.0.1:6379> BGSAVE 

Background saving started 

127.0.0.1:6379> exit 


为 了 测试 其 数据 持久 化 效 采 ， 下 面 删 除 Pod 资 源 vol-nfs-pod， 并 于 
再 次 重建 后 检测 数据 是 否 依 然 能 够 访问 : 


~]$ kubectl1 delete pods vol-nfs-pod 
pod "vol-nfs-pod" deleted 

~]$ kubect1 apply -f vol-nfs.yaml 
pod "vol-nfs-pod" created 


待 其 重建 完成 后 ， 通 过 再 一 次 创建 的 Pod 资 源 的 详细 信息 ， 我 们 
可 以 观察 到 它 挂 载 使 用 NFS 存 储 卷 的 相关 信息 。 接 下 来 再 次 检查 redis- 
server 中 是 否 还 保存 有 此 前 存储 的 数据 : 


~]$ kubect1 exec -it vol-nfs-pod redis-cli 
127.0.0.1:6379> get mykey 

"hello ilinux.io" 

127.0.0.1:6379> 


从 上 面 的 命令 结果 中 可 以 看 出 ， 此 前 创建 的 键 mykey 及 其 数据 在 
Pod 资 源 重 建 后 依然 存在 ， 这 表明 在 删除 Pod 资 源 时 ， 其 关联 的 外 部 存 
储 卷 并 不 会 被 一 同 删除 。 如 采 需 要 清除 此 类 的 数据 ， 需 要 用 户 通过 存 
储 系统 的 管理 接口 手动 进行 。 


7.4.2 ”RBD 存 储 卷 


Ceph 是 一 个 专注 于 分 布 式 的 、 弹 性 可 扩展 的 、 高 可 靠 的 、 性 能 优 
异 的 存储 系统 平台 ， 同 时 支持 提供 块 设备 、 文件 系统 和 REST 二 种 存储 
接口 。 它 是 一 个 高 度 可 配置 的 系统 ， 并 提供 了 一 个 命令 行 界面 用 于 监 
视 和 控制 其 存储 集群 。Ceph 还 包含 鉴证 和 授权 功能 ， 可 兼容 多 种 存储 
网 天 接口 ， 如 OpenStack Swift 和 Amazon S3。Kubernetes 也 支持 通过 
RBD 卷 类 型 使 用 Ceph 存 储 系 统 为 Pod 提 供 存 储 卷 。 要 配置 Pod 资 源 使 用 
RBD 存 储 卷 ， 需 要 事先 满足 如 下 几 个 前 提 条 件 。 


-存在 某 可 用 的 Ceph RBD 存 储 集群， 否则 就 需要 创建 一 个 。 


.在 Ceph RBD 集 群 中 创建 一 个 能 满足 Pod 资 源 数据 存储 需要 的 存储 
映像 (image) 


-在 Kubernetes 集 群 内 的 各 节点 上 安装 Ceph 客 户 端 程序 包 (ceph- 


common) 


在 配置 RBD 类 型 的 存储 卷 时 ， 需 要 指定 要 连接 的 目标 服务 器 和 认 
证 信息 等 ， 这 一 点 通 弟 使 用 以 下 嵌 套 字段 进行 定义 。 


:monitors<[]string>: Ceph 存 储 监 视 右 ， 和 如 号 分 隅 的 字符 串 列表 ; 
必 选 字段 。 


:image<string>: rados image 的 名 称 ， 必 选 字段 。 
.pool<string>: rados 存 储 池 和 名称 ， 默 认为 RBD 。 
-user<string>: rados 用 户 名 ， 默 认为 admin 。 


-keyring<string>: RBD 用 户 认证 时 使 用 的 keyring 文 件 路 径 ， 默 认 
为 /etc/ceph/keyring 。 


“secretRef<Object>: RBD 用 户 认证 时 使 用 的 保存 有 相应 认证 信息 的 
Secret 对 象 ， 会 覆盖 由 keyring 字 段 提供 的 密 钥 信息 。 


TeadOnly<string>: 是 否 以 只 读 的 方式 进行 访问 。 


fsType: 要 挂 载 的 存储 卷 的 文件 系统 类 型 ， 至 少 应 该 是 万 点 操作 
系统 支持 的 文件 系统 ， 如 ext4、xfs、ntfs 等 ， 默 认为 ext4。 


下 面 是 一 个 定义 在 vol-rbd.yaml 配 置 文 件 中 使 用 RBD 存 储 卷 的 Pod 资 
源 示例 |: 


apiVersion: v1 
kind: Pod 
metadata: 
name: vol-rbd-pod 
spec: 
containers: 
- name: redis 
image: redis:4-alpine 
ports: 
- containerPort: 6379 
name: redisport 
VolLumeMounts : 
- mountPath: /data 
name: redis-rbd-vol 
volumes: 
- name: redis-rbd-vol 
rbd: 
monitors: 
- '172.16.0.56:6789' 
- '172.16.0.57:6789' 
- '172.16.0.58:6789' 
pool: kube 
image: redis 
fsType: ext4 
readonly: false 
user: admin 
secretRef: 
name: ceph-secret 


此 示例 依赖 于 事先 存在 的 一 个 Ceph 存 储 集群 ， 这 里 假设 其 监视 器 
的 地 址 为 172.16.0.56、172.16.0.57 和 172.16.0.58 三 个 主机 IP， 并 且 集 群 
上 的 存储 池 kube 中 存在 创建 好 的 映像 Redis， 此 映像 拥有 ext4 文 件 系 
统 。Ceph 客 户 端 访 问 集群 时 需要 事先 完成 认证 之 后 才能 进行 后 续 的 访 
问 操作 ， 此 示例 上 ， 其 认证 信息 保存 于 名 为 ceph-secret 的 Secret 资 源 对 
象 中 。 示 例 所 实现 的 逻辑 架构 如 图 7-3 所 示 。 


Volume 
redis-rbd-vol 


图 7-3 ”RBD 存 储 卷 


@ 二 此 配置 示例 依赖 于 一 个 可 用 的 Ceph 集 群 ， 且 上 述 配 置 
示例 中 的 部 分 参数 需要 参照 实际 环境 进行 修改 。 


7.4.3 ”GlusterFS 存 储 卷 


GlusterFS (Gluster File System) 是 一 个 开源 的 分 布 式 文件 系统 ， 
是 水 平 扩展 存储 解决 方案 Gluster 的 核心 ， 具 有 强大 的 横向 扩展 能 
GlusterFS 通 过 扩展 能 够 文 持 数 PB 存 储 容量 和 处 理 数 千 客 户 端 。 
GlusterFS 借 助 TCP/IP 或 InfiniBand RDMA 网 络 将 物理 分 布 的 存储 资源 
聚集 在 一 起 ， 使 用 单一 全 局 命名 空间 来 管理 数据 。 另 外 ，GlusterFS 基 
于 可 堆 车 的 用 户 空间 设计 ， 可 为 各 种 不 同 的 数据 负载 提供 优异 的 性 
能 ， 是 男 一 种 流行 的 分 布 式 存储 解决 方案 。 要 配置 Pod 资 源 使 用 
GlusterFS 存 储 卷 ， 需 要 事先 满足 以 下 前 提 条 件 。 


1) 存在 某 可 用 的 GlusterFS 存 储 集群 ， 否 则 就 要 创建 一 个 。 
2) 在 GlusterFS 集 群 中 创建 一 个 能 满足 Pod 资 源 数据 存储 需要 的 


3) 在 Kubernetes 集 群 内 的 各 下 点 上 安装 GlusterFS 客 户 端 程序 包 
(glusterfs 和 glusterfs-fuse) 。 


另外 ， 大 要 基于 GlusterFS 使 用 存储 卷 的 动态 供给 机 制 (请 参考 
7.5.6 节 ) ， 还 需要 事先 部 署 heketi， 它 用 于 为 GlusterFS 集 群 提 供 
RESTfu 风 格 的 管理 接口 。Gluster 存 储 集群 及 heketi 的 配置 示例 请 参考 
附录 B。 


定义 Pod 资 源 使 用 GlusterFS 类 型 的 存储 卷 时 ， 常 用 的 配置 字段 包 
舍 如 下 几 个 。 


-endpoints<string>: Endpoints 资 源 的 名 称 ， 此 资源 需要 事先 存 
在 ， 用 于 提供 Gluster 集 群 的 部 分 节点 信息 作为 其 访问 入 口 ; 必 选 字 
段 。 


:path<string>: 用 到 的 GlusterFS 集 群 的 卷 路 径 ， 如 kube-redis; 必 
选 字段 。 


:readOnly<boolean>: 是 否 为 只 恋 卷 。 


下 面 是 一 个 定义 在 vol-glusterfs. ee 各 源 示例 ， 
它 使 用 了 GlusterFS 存 储 卷 持久 你 存 应 用 数据 。 它 通过 glusterfs- 
endpoints 资 源 中 定义 的 GlusterFS 集 群 节 点 信息 接 入 集群 ， 并 以 kube- 
redis 卷 作为 Pod 资 源 的 存储 卷 。glusterfs-endpoints 资 源 需 要 在 
Kubernetes 集 群 中 事先 创建 ， 而 kube-redis 则 和 需要 事先 创建 于 Gluster 集 
群 : 


apiVersion: v1 
kind: Pod 
metadata: 
name: vol-glusterfs-pod 
labels: 
app: redis 
spec: 
containers: 
- name: redis 
image: redis:alpine 
ports: 
- containerPort: 6379 
name: redisport 
volumeMounts: 
- mountPath: /data 
name: redisdata 
volumes: 
- name: redisdata 
glusterfs : 
endpoints: glusterfs-endpoints 
path: kube-redis 
readonly: false 


用 于 访问 Gluster 集 群 的 相关 下 点 信息 要 事先 保存 于 某 特 定 的 
Endpoints 资 源 中 ， 例 如 上 面 示例 中 调用 的 glusterfs-endpoints。 此 类 的 
Endpoints 资 源 可 由 用 户 根 据 实际 需求 手动 创建 例如， 下面 的 保存 于 
glusterfs- endpointsyaml 文 件 中 的 资源 示例 中 定义 了 三 个 接 入 相关 的 
Gluster 存 储 集群 的 节点 gfs01.ilinux.io、gfs02.ilinux.io 和 gfs03.ilinux.io， 
J 山口 信息 仪 为 满足 Endpoints 资 源 的 必 选 字段 要 求 ， 因 此 其 [ 值 可 
以 随意 填 


apiVersion: v1 
kind: Endpoints 
metadata.: 
name: glusterfs-endpoints 
subsets: 
- addresses : 
- ip: gfs01.ilinux.io 
ports: 
- port: 24007 
name: glusterd 


- addresses : 
- ip: gfs02.ilinux.io 
ports: 
- port: 24007 
name: glusterd 
- addresses : 
- ip: gfs03.ilinux.io 
ports: 
- port: 24007 
name: glusterd 


首先 创建 Endpoints 资 源 glusterfs-endpoints， 而 后 再 创建 Pod 资 源 
vol-glusterfs-pod， 即 可 测试 其 数据 持久 存储 的 效果 。 


7.4.4 ” ”Cinder 存储 卷 


Cinder 是 OpenStack Block Storage 的 项 目 名 称 ， 用 来 为 虚拟 机 
(VM) 实例 提供 持久 块 存储 。Cinder 通 过 驱动 架构 支持 多 种 后 端 
(back-end) 存储 方式 ， 包 括 LYM、NFS、Ceph 和 其 他 诸如 EMC 、 

IBM 等 商业 存储 产品 和 方案 ， 其 提供 了 调用 度 来 调度 卷 创 建 的 请 求 ， 
能 合理 优化 存储 资源 的 分 配 ， 而 且 还 拥有 REST API。 将 Kubernetes 集 
群 部 署 于 OpenStack 构 建 的 IaaS 环 境 中 时 ，Cinder 的 块 存储 功能 可 为 Pod 
资源 提供 外 部 持久 存储 的 有 效 方式 。 


在 Pod 资 源 上 定义 使 用 Cinder 存 储 卷 时 ， 其 可 用 的 藤 父 字段 包含 如 
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volumeID<string>， 用 于 标识 Cinder 中 的 存储 卷 的 卷 标识 符 ， 必 先 
字段 。 


TeadOnly<boolean>: 是 否 以 只 读 方 式 访问 。 


fsType: 要 挂 载 的 存储 卷 的 文件 系统 类 型 ， 至 少 应 该 是 节点 操作 
系统 支持 的 文件 系统 ， 如 ext4、xfs、ntfs 等 ， 默 认为 “ext4”。 


下 面 的 资源 清单 是 定义 在 vol-cinderyaml 文 件 中 的 使 用 示例 ， 假 设 
在 OpenStack 环 境 中 有 创建 好 的 Cinder 卷 <e2b8d2f7-wece-90d1-a505- 
4acf607a90bc” 可 用 : 


apiVersion: v1 
kind: Pod 
metadata: 
name: vol-cinder-pod 
spec: 
containers: 
- image: mysql 
name: mysql 
args: 
- "--ignore-db-dir" 
- "lost+found" 
env: 
- Name: MYSQL_ROOT_PASSWORD 
value: YOUR_PASS 
ports: 
- containerPort: 3306 
name: mysqlport 


volumeMounts: 
- name: mysqldata 
mountPath: /var/lib/mysql 
volumes: 
- name: mysqldata 
cinder: 


volumeID: e2b8d2f7-wece-90d1-a505-4acf607a90bc 
fsType: ext4 


配置 可 用 的 系统 环境 和 存储 资源 时 ， 将 其 匹配 于 资源 清单 文件 中 
即 可 完成 Pod 资 源 创建 。 另 外 ，Kubernetes 所 文 持 的 各 类 持久 存储 卷 其 
配置 使 用 方式 各 有 不 同 ， 鉴 于 篇 幅 有 限 ， 这 里 不 再 一 一 列举 其 使 用 方 


式 。 


7.5 持久 存储 卷 


通过 前 面 使 用 持久 存储 卷 (Persistent Volume) 的 示例 可 知 ， 

Kubernetes 用 户 必须 要 清晰 了 解 所 用 到 的 网 络 存储 系统 的 访问 细 太 才能 
完成 存储 卷 相 关 的 配置 任务 ， 例 如 ，NFS 存 储 卷 的 server 和 path 字 段 的 
配置 就 依赖 于 服务 器 地 址 和 共享 目录 路 径 。 这 与 Kubernetes 的 向 用 户 和 
开发 隐藏 底层 架构 的 目标 有 所 背离 ， 对 存储 资源 的 使 用 最 好 也 能 像 使 
用 计算 资源 一 样 ， 用 户 和 开发 人 员 无 顷 了 解 Pod 资 源 究 竟 运 行 于 哪个 和 
点 ， 也 无 须 了 解 存 储 系 统 是 什么 设备 以 及 位 于 何 处 。 为 此 ，Kubernetes 
的 PersistentVolume 子 系统 在 用 户 与 管理 员 之 间 添 加 了 一 个 抽象 层 ， 从 
而 使 得 存储 系统 的 使 用 和 管理 职能 互相 解 耘 ， 如 图 7-4 所 示 。 


PersistentVolume (PV) 是 指 由 集群 管理 员 配 置 提供 的 某 存储 系统 
上 的 一 段 存 储 空间 ， 它 是 对 底层 共享 存储 的 抽象 ， 将 共享 存储 作为 一 
种 可 由 用 户 申请 使 用 的 资源 ， 实 现 了 “存储 消费 机制。 通过 存储 插件 
机 制 ，PV 文 持 使 用 多 种 网 络 存储 系统 或 云端 存储 等 多 种 后 端 存储 系 
统 ， 例 如 ， 前 面 使 用 的 NES、RBD 和 Cinder 等 。PV 是 集群 级 别 的 资 
源 ， 不 属于 任何 名 称 空间 ， 用 户 对 PV 资 源 的 使 用 需要 通过 
PersistentVolumeClaim (PVC) 提出 的 使 用 申请 〈 或 称 为 声明 ) 来 完成 
绑 定 ， 是 PV 资源 的 消费 者 ， 它 向 PV 申请 特定 大 小 的 空间 及 访问 模式 

(如 rw 或 ro) ， 从 而 创建 出 PVC 存 储 卷 ， 而 后 再 由 Pod 资 源 通 过 

PersistentVolumeClaim 存 储 卷 关联 使 用 ， 如 图 7-4 所 示 。 


kubernetes cluster 
namespace 
”> Storage 
A Pod \ 
/ \ 
| | 
\ Ba 
# | 
Users and Developers Cluster admin Storage admin 
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E> > [2] 
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图 7-4 Pod 存 储 卷 、PVC、PV 及 存储 设备 的 调用 关系 


民生 VC 例 得 用 户 可 以 久 招 陀 的 广 志 订 加 在 销 吕 众 源 ， 但 很 多 时 候 
还 是 会 涉及 PV 的 不 少 属性 ， 例 如 ， 用 于 不 同 场景 时 设置 的 性 能 参数 
等 。 为 此 ， 集 群 管理 员 不 得 不 通过 多 种 方式 提供 多 种 不 同 的 PV 以 满足 
用 户 不 同 的 使 用 需求 ， 两 者 衔接 上 的 偏差 必然 会 导致 用 户 的 需求 无 法 
全 部 及 时 有 效 地 得 到 满足 。Kubernetes 自 1.4 版 起 引入 了 一 个 新 的 资源 对 
象 StorageClass， 可 用 于 将 存储 资源 定义 为 具有 显著 特性 的 类 别 

(Class) 而 不 是 具体 的 PV， 例 
如 “fast”“slow” 或 <glod”“silver”“bronze” 等 。 用 户 通 过 PVC 直 接 回 意 辐 的 
类 别 发 出 申请 ， 匹配 由 管理 员 事 先 创建 的 PV 或 者 由 其 按 需 为 用 户 动 
态 创建 PV， 这 样 做 甚至 免 去 了 需要 事先 创建 PV 的 过 程 。 


PV 对 存储 系统 的 文 持 可 通过 其 插件 来 实现 ， 目 前 ，Kubernetes 文 持 
如 下 类 型 的 插件 。 


‘GCEPersistentDisk 


‘AWSElasticBlockStore 
‘AzureFile 

‘AzureDisk 

‘FC (Fibre Channel) ** 
:FlexVolume 

‘Flocker 

‘NFS 

“iSCSI 

‘RBD (Ceph Block Device) 
‘CephFS 


Cinder (OpenStack block storage) 


‘Glusterfs 
‘VsphereVolume 
‘Quobyte Volumes 
:HostPath 
“VMware Photon 
‘Portworx Volumes 
‘ScalelO Volumes 


‘StorageOS 


7.5.1 创建 PV 


PersistentVolume Spec 主 要 文 持 以 下 几 个 通用 字段 ， 用 于 定义 PV 的 
容量 、 访 问 模式 和 回收 策略 。 


1) Capacity: 当前 PV 的 容量 ， 目 前 ，Capacity 仅 文 持 空 间 设 定 ， 
将 来 应 该 还 可 以 指定 IOPS 和 throughput 。 


2) 访问 模式 ， 尽管 在 PV 层 看 起 来 并 无 老 别 ， 但 存储 设备 文 持 及 局 
用 的 功能 特性 却 可 能 不 尽 相 同 。 例 如 NEFS 存 储 文 持 多 客户 端 同时 挂 载 及 
读 写 操作 ， 但 也 可 能 是 在 共享 时 仅 启 用 了 只 读 操作 ， 其 他 存储 系统 
存在 类 似 的 可 配置 特性 。 因 此 ，PV 底 层 的 设备 或 许 存 在 其 特有 的 访问 
模式 ， 用 户 使 用 时 必须 在 其 特性 范围 内 设 定 其 功能 ， 具 体 如 图 7-5 所 
冰 。 


ReadWriteOnce: 仅 可 被 单个 下 点 读 写 挂 载 ， 命 令 行 中 商 写 为 
RWO。 


ReadOnlyMany: 可 被 多 个 市 点 同时 只 读 挂 载 ， 命 令 行 中 简写 为 
ROX 。 


-ReadWriteMany: 可 被 多 个 证 点 同时 读 写 挂 载 ， 命 令 行 中 简写 为 
RWX ° 


3) persistentVolumeReclaimPolicy: PV 空 间 被 释放 时 的 处 理 机 制 ; 
可 用 类 型 仅 为 Retain (默认 ) 、Recycle 或 Delete， 具 体 说 明 如 下 。 


:Retain: 保持 不 动 ， 由 管理 员 随 后 手动 回收 。 


-Recycle: 空间 回收 ， 即 删除 存储 卷 目 孙 下 的 所 有 文件 (包括 子 目 
录 和 隐藏 文件 ) ， 目 前 仅 NFES 和 hostPath 文 持 此 操作 。 


.Delete: 删除 存储 卷 ， 仅 部 分 云端 存储 系统 文 持 ， 如 AWS EBS、 
GCE PD、Azure Disk 和 Cinder 。 


4) volumeMode: 卷 模型 ， 用 于 指定 此 卷 可 被 用 作文 件 系 统 还 是 裸 
格式 的 块 设备 ;默认 为 Filesystem。 


5) storageClassName: 当前 PV 所 属 的 StorageClass 的 名 称 ; 默认 为 
空 值 ， 即 不 属于 任何 StorageClass。 


6) mountOptions: 挂 载 选项 组 成 的 列表 ， 如 ro、soft 和 hard 等 。 


Volume Plugin ReadWriteOnce ReadOnlyMany ReadWriteMany 
AWSElasticBlockStore V 

AzureFile NA Vv V 
AzureDisk ~ 

CephFS V V V 
Cinder V 

FC NA V 

FlexVolume ~ V 

Flocker ~ 

GCEPersistentDisk V V 

Glusterfs ~ V V 
HostPath ~ 

iSCSI V V 

PhotonPersistentDisk V 

Quobyte ~ Vv V 
NFS V A V 
RBD V V 

VsphereVolume V - - (works when pods are collocated) 
PortworxVolume V = ~ 
ScalelO V V 

Storage0S V 


图 7-5 ”各 PV 支持 的 访问 模式 


下 面 的 资源 清单 配置 示例 中 定义 了 一 个 使 用 NFS 存 储 后 端的 PV， 
空间 大 小 为 10GB， 文 持 多 路 的 读 写 操作 。 答 后 端 存 储 系统 满足 需 来 
时 ， 即 可 进行 如 下 PV 资源 的 创建 : 


kind: PersistentVolume 
metadata: 
name: pv-nfs-0001 
Jabels: 
release: stable 
spec: 


capacity: 

storage: 56Gi 
volumeMode: Filesystem 
accessModes: 

- ReadwriteMany 
persistentVolumeReclaimPolicy: Recycle 
storageClassName: slow 
mountoptions : 

- hard 

- nfsvers=4.1 
nfs: 

path: "/webdata/htdocs" 

server: nfs.ilinux.io 


创建 完成 后 ， 可 以 看 到 其 状态 为 “Available”， 即 “可 用 ”状态 ， 表 示 
目前 尚未 被 PVC 资 源 所 <“ 绑 定 ”: 


~]$ kubect] get pv pv-nfs-0001 -0 custom-columns=NAME:metadata.name,STATUS:status. 
phase 

NAME STATUS 

pv-nfs-0001 Available 


下 面 是 男 一 个 PV 资源 的 配置 清单 ， 它 使 用 RBD 存 储 后 端 ， 空 间 大 
小 为 2GB， 仪 支持 单个 客户 端的 读 写 访问 。 将 RBD 相 关 属 性 设 定 为 匹 
配 实际 的 环境 需求 ， 例 如 在 Ceph 和 集群 中 创建 映像 pv-rbd-0001， 大 小 为 
0 
源 : 


apiVersion: v1 
kind: PersistentVolume 
metadata: 
name: pv-rbd-0001 
spec: 
capacity: 
storage: 26Gi 
accessModes: 
- Readwriteonce 
rbd: 
monitors: 
- Ceph-monO1.ilinux.io:6789 
- Ceph-monO2.ilinux.io:6789 
- Ceph-monO3.ilinux.io:6789 
pool: kube 
image: pv-rbd-0001 
user: admin 
SecretRef : 
name: ceph-secret 
fsType: ext4 
readonly: false 
persistentVolumeReclaimPolicy: Retain 


使 用 资源 的 查看 命令 可 列 出 PV 资 源 的 相关 信息 。 创 建 完 成 的 PV 资 
源 可 能 处 于 下 列 四 种 状态 中 的 某 一 种 ， 它 们 代表 着 PV 资源 生命 周期 中 
的 各 个 阶段 。 

.Available: 可 用 状态 的 目 由 资源， 尚未 被 PVC 绑 定 。 

.Bound: 已 经 绑 定 至 某 PVC 。 

:Released: 绑 定 的 PVC 已 经 被 删除 ， 但 资源 尚未 被 集群 回收 。 


Failed: 因 目 动 回 收 货源 失败 而 处 于 的 故障 状态 。 


7.5.2 ”创建 PVC 


PersistentVolumeClaim 是 存储 卷 类 型 的 资源 ， 它 通过 申请 占用 某 个 
PersistentVolume 而 创建 ， 它 与 PV 是 一 对 一 的 关系 ， 用 户 无 须 关 心 其 底 
层 实现 细 和 。 申 请 时 ， 用 户 只 需要 指定 目标 空间 的 大 小 、 访 问 模式 、 
PV 标签 选择 絮 和 StorageClass 等 相关 信息 即 可 。PVC 的 Spec 字 上 段 的 可 山 
套 字 上 段 具体 如 下 。 


accessMode: 当前 PVC 的 访问 模式 ， 其 可 用 模式 与 PV 相同 。 


TeSOUTCeS: 当前 PVC 存 储 卷 需 要 占用 的 资源 量 最 小 值 ， 目 前 ， 
PVC 的 资源 限定 仅 指 其 空间 大 小 。 

.selector: 绑 定 时 对 PV 应 用 的 标签 选择 器 (matchLabels) 或 匹配 
条 件 表达 式 (matchEx- 


:pressions) ， 用 于 挑选 要 绑 定 的 PV; 如 果 同 时 指定 了 两 种 挑选 机 
制 ， 则 必须 同时 满足 两 种 选择 机 制 的 PV 才 能 被 选 出 。 

'storageClassName: 所 依赖 的 存储 类 的 名 称 。 

volumeMode: 卷 模型 ， 用 于 指定 此 卷 可 被 用 作文 件 系统 还 是 裸 
格式 的 块 设备 ;默认 为 "Filesystem”。 

volumeName: 用 于 直接 指定 要 绑 定 的 PV 的 卷 名 。 

下 面 的 配置 清单 (pvc-nfs-0001.yaml 文 件 ) 定义 了 一 个 PVC 资 源 示 
例 ， 其 选择 PV 的 挑选 机 制 是 使 用 了 标签 选择 絮 ， 适 配 的 标签 是 


release: stable， 存 储 类 为 slbow， 这 会 天 联 到 前 面 创建 的 PV 资源 pv-nfs- 
0001: 


apiVersion: v1 
kind: PersistentVolumeClaim 


metadata: 
name: pvc-nfs-0001 
Jables: 
release: “stable” 
spec: 


accessModes: 


- ReadwriteMany 
volumeMode: Filesystem 
resources: 

requests: 

storage: 5Gi 
storageClassName: slow 
selector: 

matchLabels: 

release: "stable" 


Ts 令 完成 资源 创建 ， 而 后 即 可 查看 其 绑 定 PV 资 源 的 
日 天 信息 


~]$ kubect1 get pvc pvc-nfs-0001 
NAME STATUS _ VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE 
pvc-nfs-0001 Bound pv-nfs-0001 56Gi RWX slow 6s 


如 果 需 要 绑 定 此 六 创建 的 PV 痪 务 源 pv-rbd-0001， 那 么 创建 类 似 如 下 
的 资源 配置 即 可 ， 它 将 保存 于 配置 文件 pvc- rbd-0001.yaml 中 : 


apiVersion: v1 
kind: PersistentVolumeClaim 
metadata: 
name: pvc-rbd-0001 
spec: 
accessModes: 

- Readwriteonce 
volumeMode: Filesystem 
resources: 

requests: 

storage: 26Gi 
storageClassName: fast 
selector: 

matchLabels: 

release: "stable" 


” 0 贷 源 创建 命令 完成 资源 创建 ， 而 后 即 可 查看 其 绑 定 PV 资源 的 
天 信息 : 


~]$ kubect1 get pvc/pvc-rbd-0001 
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE 
pvc-rbd-0001 Bound pv-rbd-0001 26G1 RWO fast 5s 


创建 好 PVC 资 源 之 后 ， 即 可 在 Pod 资 源 有 中 通过 persistenVolumeClain 
存储 卷 引 用 它 ， 而 后 挂 载 于 容器 中 进行 数据 持久 化 。 需 要 注意 的 是 ， 


PV 是 集群 级 别 的 货源 ， 而 PVC 则 隶属 于 名 称 空 间 ， 因 此 ，PVC 在 绑 定 
目标 PV 时 不 受 名 称 空 间 的 限制 ， 但 Pod 引 用 PVC 时 ， 则 只 能 是 属于 同 
一 名 称 空间 中 的 资产 。 


7.5.3 ”在 Pod 中 使 用 PVC 


在 Pod 资 源 中 调用 PVC 资 源 ， 只 需要 在 定义 volumes 时 使 用 
persistentVolumeClaims 字 上 段 藤 套 指 定 两 个 字段 即 可 ， 具 体 如 下 。 


-claimName: 要 调用 的 PVC 存 储 卷 的 名 称 ，PVC 卷 要 与 Pod 在 同一 
名 称 空间 中 。 


:readOnly: 是 否 将 存储 卷 强 制 挂 载 为 只 读 模 式 ， 默 认为 false。 
下 面 的 清单 定义 了 一 个 Pod 资 源 ， 它 是 7.4.2 世 中 直接 使 用 RBD 存 


储 0 ， 此 处 改 为 调用 了 前 面 刚刚 创建 的 名 为 pv-rbd-0001 的 PVC 
资 浊 sy: 


apiVersion: v1 
kind: Pod 
metadata: 
name: vol-rbd-pod 
spec: 
containers: 
- name: redis 
image: redis:4-alpine 
ports: 
- CcontainerPort: 6379 
name: redisport 
volumeMounts: 
- mountPath: /data 
name: redis-rbd-vol 
volumes: 
- name: redis-rbd-vol 
persistentVolumeClaim: 
claimName: pv-rbd-0001 


资源 创建 完成 后 ， 即 可 通过 类 似 于 此 前 7.4.1 市 示例 中 的 方式 完成 
数据 持久 性 测试 。 


7.5.4 ”存储 类 


存储 类 (storage class) 是 Kubernetes 资 源 类 型 的 一 种 ， 它 是 由 管理 


员 为 管理 PV 之 便 而 按 需 创建 的 类 别 (逻辑 组 ，， 例 如 可 按 存 全 上 充 的 
性 能 高 低 分 类 ， 或 者 根据 其 综合 服务 质量 级 别 进行 分 类 (如 图 7-6 所 
示 ) 、 依 照 备份 策略 分 类 ， 甚 至 直接 按 管理 员 自 定义 的 标准 进行 分 类 
等 。 不 过 ，Kubernetes 目 身 无 法 理解 “类 别 ” 到 搬 意 味 着 什么 ， 它 仅仅 是 
将 这 些 当 作 PV 的 特性 描述 。 


Gold Storage Class Silver Storage Class Bronze Storage Class 


OO 故国 上 是 soa 
[1 0 es 


图 7-6 ”基于 绿 合 服务 质量 的 存储 系统 分 类 


存储 类 的 好 处 之 一 便 是 支持 PV 的 动态 创建 。 用 户 用 到 持久 性 存储 
时 ， 需 要 通过 创建 PVC 来 绑 定 匹配 的 PV， 此 类 操作 需求 量 较 大 ， 或 者 
当 管理 员 手 动 创建 的 PV 无 法 满足 PVC 的 所 有 需求 时 ， 系 统 按 PVC 的 需 
求 标准 动态 创建 适 配 的 PV 会 为 存储 管理 市 来 极 大 的 灵活 性 。 


存储 类 对 象 的 名 称 至 关 重 要 ， 它 是 用 户 调用 的 标识 。 创 建 存储 类 
对 象 时 ， 除 了 名 称 之 外 ， 还 需要 为 其 定义 三 个 关键 字段 : provisioner、 


parameter 和 reclaimPolicy ° 


1.StorageClass Spec 
StorageClass Spec 中 的 字段 是 定义 存储 类 时 最 重要 的 字段 ， 其 包 
以 下 五 个 可 用 字段 。 
-provisioner 〈 供 给 方 ) : 即 提供 了 存储 资源 的 存储 系统 ， 存 储 类 要 


依赖 Provisioner 来 判定 要 使 用 的 存储 插件 以 便 适 配 到 目 标 存储 系统 
Kubernetes 内 建 有 多 种 供给 方 (Provisioner) ， 这 些 供给 方 的 名 字 都 


以 “kubernetes.io” 为 前 缀 。 另 外 ， 它 还 文 持 用 户 依据 Kubernetes 规 范 目 定 


XProvisioner 。 


:parameters (参数 ) : 存储 类 使 用 参数 撒 述 要 关联 到 的 存储 卷 ， 不 
过 ， 不 同 的 Provisioner 可 用 的 参数 各 不 相同 。 


TeclaimPolicy: 为 当前 存储 类 动态 创建 的 PV 指定 回收 策略 ， 可 用 
值 为 Delete (默认 ) 和 Retain; 不 过 ， 那 些 由 管理 员 手 工 创建 的 PV 的 回 
收 菏 上 略 则 取决 于 它们 目 身 的 定义 。 


-volumeBindingMode: 定义 如 何 为 PVC 完 成 供给 和 绑 定 ， 默 认 值 
为 “VolumeBinding Immediate”; 此 选项 仅 在 启用 了 存储 卷 调度 功能 时 才 
能 生效 。 


-mountOptions: 由 当前 类 动态 创建 的 PV 的 挂 载 选 项 列表 。 
下 面 是 一 个 定义 在 glusterfs-storageclass.yaml 配 置 文件 中 的 资源 清 


单 ， 它 定义 了 一 个 使 用 Gluster 存 储 系统 的 存储 类 glusterfs， 并 通过 
aniotatiors 字 段 将 其 定义 为 默认 的 存储 类 : 


kind: StorageClass 
apiVersion: storage.k8s.io/vibetal1 
metadata: 
name: glusterfs 
provisioner: kubernetes.io/glusterfs 
parameters: 
resturl: "http://heketi.ilinux.io:8080" 
restauthenabled: "false" 
restuser: "ik8s" 
restuserkey: "ik8s.io" 


这 里 需要 特别 提醒 读者 的 是 ，parameters.resturl 字 段 用 于 指定 
Gluster 存 储 系 统 的 RESTful 风 格 的 访问 接口 ， 本 示例 中 使 用 
的 “http://heketi.ilinux.io:8080 ”应 殖 换 为 读者 自己 实际 环境 中 的 可 用 地 
址 。Gluster 存 储 系统 本 身 并 不 支持 这 种 访问 方式 ， 管 理 员 需 要 额外 部 
署 heketi 配 合 Gluster 以 提供 此 类 服务 接口 。Heketi 文 持 认 证 访问 ， 不 过 
只 有 在 restauthenabled 设 置 为 "true” 时 ，restuser 和 restuserkey 字 段 才 会 局 
用 。Heketi 的 设置 及 使 用 方式 请 参考 附 孙 B。 


2. 动 态 PV 供 给 


动态 PV 供给 的 启用 ， 需 要 事先 由 管理 员 创建 至 少 一 个 存储 类 ， 不 
同 的 Provisoner 的 创建 方法 各 有 不 同 ， 具 体内 容 如 前 一 节 所 示 。 男 外 ， 
i 的 ne 由 Kubernetes 内 建文 持 PV 动 态 供给 功能 ， 具 体 
言 息 如 图 7-7 所 示 。 


上 文中 定义 glusterfs 存 储 类 资源 创建 完成 后 ， 便 可 以 据 此 使 用 动态 
PV 供 给 功能 。 下 面 的 资源 清单 定义 在 pvc-gluserfs-dynamic-0001.yaml 配 
置 文件 中 ， 它 将 从 glusterfs 存 储 类 中 申请 使 用 5GB 的 存储 空间 : 


apiVersion: v1 
kind: PersistentVolumeClaim 
metadata: 
name: pvc-gluster-dynamic-0001 
annotations: 
volume.beta.kubernetes.io/storage-class: glusterfs 
spec: 
# storageClassName: "glusterfs" 
accessModes: 
- ReadwriteOonce 
resources: 
requests: 
storage: 5G1i 


Volume Plugin Internal Provisioner 


AWSElasticBlockStore V 
AzureFile V 
AzureDisk V 
CephFS 

Cinder Vv 
FC 

FlexVolume 

Flocker V 
GCEPersistentDisk V 
Glusterfs V 
iSCSI 

PhotonPersistentDisk V 
Quobyte V 
NFS 

RBD V 
VsphereVolume V 
PortworxVolume Vv 
ScalelO V 
Storage0S V 
Local 


图 7-7 ”各 存储 插件 对 动态 供给 方式 的 文 持 状况 
目前 ， 在 PVC 的 定义 中 指定 使 用 的 存储 类 资源 的 方式 共有 两 种 : 


一 种 是 使 用 Spec.storageClassName 字 段 ， 另 一 种 是 使 

用 “volume.beta.kubernetes.io/storage-class” 注 解 信息 ， 如 上 面 示例 中 所 
示 “。 不 过 ， 建 议 仅 使 用 一 种 方式 ， 以 免 两 者 设置 为 不 同 的 值 时 会 出 现 
配置 错误 。 接 下 来 创建 定义 的 PVC， 并 检查 其 绑 定 状态 : 


~]$ kubect] create -f pvc-glusterfs-dynamic-0001.yamJ 
persistentvolumeclaim "pvc-gluster-dynamic-0001" created 


通过 如 下 命令 输出 的 PVC 资 源 的 摘 述 信息 可 以 看 到 ，PVC 存 储 卷 
已 创建 完成 旦 已 经 完成 了 PV 绑 定 ， 绑 定 的 PV 资 源 由 persistentvolume- 
controller 控 制 妖 动态 提供 : 


~]$ kubectl describe pvc pvc-gluster-dynamic-0001 


Name: pvc-gluster-dynamic-0001 

Namespace default 

StorageClass: glusterfs 

Status: Bound 

Volume: pvc-5836eb47-6c77-11e8-9bab-000c29be4e28 
Labels: <none> 

Annotations: pv.kubernetes.io/bind-completed=yes 


pv.kubernetes.io/bound-by-controller=yes 
volume.beta.kubernetes.io/storage- 
provisioner=kubernetes.io/glusterfs 


Finalizers: [kubernetes.io/pvc-protection] 
Capacity: 5G1i 
Access Modes: RWO 
Events: 
Type Reason Age From Message 


provisioned volume pvc-5836eb47-6c77-11e8-9bab-000c29be4e28 using 
kubernetes. 
io/glusterfs 


任何 支持 PV 动态 供给 的 存储 系统 都 可 以 在 定义 为 存储 类 后 由 PVC 
动态 申请 使 用 ， 这 对 于 难以 事先 预 估 使 用 到 的 存储 空间 大 小 及 存储 卷 
数量 的 使 用 场景 尤为 有 用 ， 例 如 由 StatefulSet 控 制 絮 管理 Pod 对 和 象 时 ， 
0 资源 ， 且 随 着 规模 的 变动 ， 存 储 卷 的 数量 也 会 随 之 变 
A O 〇 


另外 ， 用 户 也 可 以 使 用 云端 存储 提供 的 PV 动 态 供给 机 制 ， 如 AWS 
EBS、AzureDisk、Cinder 或 GCEPersistentDisk 等 ， 将 Kubermetes 部 署 于 
Iaas 云 端 时 ， 此 种 存储 方式 使 用 的 较 多 。 各 类 云 存 储 动态 供给 的 具体 使 
用 方式 请 参考 相关 的 使 用 手册 。 


7.5.5 PV 和 PVC 的 生命 周期 


PV 是 Kubernetes 集 群 的 存储 资源 ， 而 PVC 则 代表 着 资源 需求 。 创 
建 PVC 时 对 PV 发 起 的 使 用 申请 ， 即 为 “ 绪 定 *。PV 和 PVC 是 一 一 对 应 的 
关系 ， 可 用 于 响应 PVC 申 请 的 PV 必须 要 能 够 容纳 PVC 的 请 求 条件 ， 它 
们 二 者 的 交互 遵循 如 下 生命 周期 。 


1. 和 存储 供给 


存储 供给 (Provisioning) 是 指 为 PVC 准 备 可 用 PV 的 机 制 。 
Kubernetes 支 持 两 种 PV 供给 方式 ， 静态 供给 和 动态 供给 。 


(1) 静态 供给 


静态 供给 是 指 由 集群 管理 员 手 动 创 建 一 定数 量 的 PV 的 资源 供应 方 
式 。 这 些 PV 人 负责 处 理 存储 系统 的 细 方 ， 并 将 其 抽象 成 易 用 的 存储 资源 
供用 户 使 用 。 静 态 提供 的 PV 可 能 属于 某 存 储 类 (StorageClass) ， 也 可 
能 没有 存储 类 ， 这 一 点 取决 于 管理 员 的 设 定 。 


(2) 动态 供给 


不 存在 某 静 态 的 PV 匹 配 到 用 户 的 PVC 申 请 时 ，Kubernetes 集 群 会 
党 试 为 PVC 动 态 创建 符合 需求 的 PV， 此 即 为 动态 供给 。 这 种 方式 依赖 
于 存储 类 的 辅助 ，PVC 必 须 回 一 个 事先 存在 的 存储 类 发 起 动态 分 配 PV 
的 请 求 ， 没 有 指定 存储 类 的 PVC 请 求 会 被 禁止 使 用 动态 创建 PV 的 方 


大 


另外 ， 为 了 文 持 使 用 动态 供给 机 制 ， 集 群 管理 员 需 要 为 准 入 控制 
人 絮 (admission controller) 启用 “DefaultStorageClass” 选 项 ， 这 一 点 通 
过 “--admission-control” 命 令 行 选项 为 API Server 进 行 设 定 即 可 ， 后 文 会 
对 准 入 控制 器 予以 描述 。 


2. 存 储 绑 定 


用 户 基 于 一 系列 存储 需求 和 访问 模式 定义 好 PVC 后 ，Kubernetes 系 
统 的 控制 器 即 会 为 其 查找 匹配 的 PY， 并 于 找到 之 后 在 此 二 者 之 间 建 立 


起 关联 关系 ， 而 后 它们 二 者 之 间 的 状态 即 转 为 “ 绑 定 ”(Binding) 。 若 
PV 是 为 PVC 而 动态 创建 的 ， 则 该 PV 专用 于 其 PVC 。 


若是 无 法 为 PVC 找 到 可 匹配 的 PV， 则 PVC 将 一 直 处 于 未 绑 定 
(unbound) 状态 ， 直 到 有 符合 条 件 的 PV 出 现 并 完成 绑 定 方才 可 用 。 


(1) 存储 使 用 (Using) 


Pod 资 源 基 于 persistenVolumeClaim 卷 类 型 的 定义 ， 将 选 定 的 PVC 
天 联 为 存储 卷 ， 而 后 即 可 为 内 部 的 容 絮 所 使 用 。 对 于 支持 多 种 访问 模 
式 的 存储 卷 来 说 ， 用 户 需 要 额外 指定 要 使 用 的 模式 。 一 旦 完成 将 存储 
卷 挂 载 宇 Pod 对 象 内 的 容 絮 中 ， 其 应 用 即 可 使 用 关联 的 PV 提供 的 存储 


空间 。 
(2) PVC 保 护 (Protection) 


为 了 避免 使 用 中 的 存储 卷 被 移 除 而 导致 数据 丢失 ，Kubernetes 目 
1.9 版 本 起 引入 了 “PVC 保 护 机 制 *。 局 用 了 此 特性 后 ， 万 一 有 用 户 删 除 
了 仍 处 于 某 Pod 资 源 使 用 中 的 PVC 时 ，Kubernetes 不 会 立即 予以 移 除 ， 
而 是 推迟 到 不 再 被 任何 Pod 资 源 使 用 后 方才 执行 删除 操作 。 处 于 此 种 
阶段 的 PVC 资 源 的 status 字 段 为 “Termination”， 并 且 其 Finalizers 字 段 中 
包含 “kubernetes.io/pvc-protection”。 


3. 存 储 回 收 (Reclaiming) 
完成 存储 卷 的 使 用 目标 之 后 ， 即 可 删除 PVC 对 象 以 便 进行 资源 回 


收 。 不 过 ， 至 于 如 何 操 作 则 取决 于 PV 的 回收 策略 。 目 前 ， 可 用 的 回收 
策略 有 三 种 : Retained、Recycled 和 Deleted 。 


(1) 留存 (Retain) 


留存 策略 意味 着 在 删除 PVC 之 后 ，Kubermetes 系 统 不 会 自动 删除 
pV， 而 仅仅 是 将 它 置 于 “释放 ” (released) 状态 。 不 过 ， 此 种 状态 的 
pV 尚且 不 能 被 其 他 PVC 申 请 所 绑 定 ， 因 为 此 前 的 申请 生成 的 数据 仍然 
存在 ， 需 要 由 管理 员 手动 决定 其 后 续 处 理 方案 。 这 就 意味 着 ， 如 果 想 
要 于 次 使 用 此 美的 PV 资 源 ， 则 需要 由 管理 员 按 下 面 的 步 呈 手动 执行 
祭 操作 。 


1) 删除 PV， 这 之 后 ， 此 PV 的 数据 依然 留存 于 外 部 的 存储 之 上 。 
2) 手工 清理 存储 系统 上 依然 留存 的 数据 。 


3) 手工 删除 存储 系统 级 的 存储 卷 (例如 ，RBD 存 储 系统 上 的 
image) 以 释放 空间 ， 以 便 再 次 创建 ， 或 者 直接 将 其 重新 创建 为 PV 。 


(2) 回收 (Recydle) 


如 琳 可 被 的 层 存储 插件 支持 ， 资 源 回 收集 略 会 在 存储 卷 上 执行 数 
据 删 除 操作 并 让 PV 资源 再 次 变 为 可 被 Claim。 男 外 ， 管 理 员 也 可 以 配 
置 一 个 目 定 义 的 回收 姻 Pod 模 板 ， 以 便 执 行 目 定义 的 回收 操作 。 不 
过 ， 此 种 回收 策略 行将 废弃 。 


(3) 删除 (Delete) 


对 于 支持 Deleted 回 收 策略 的 存储 插件 来 说 ， 在 PVC 被 删除 后 会 直 
接 移 除 PV 对 象 ， 同 时 移 除 的 还 有 PV 相关 的 外 部 存储 系统 上 的 存储 资 
产 (asset) 。 支 持 这 种 操作 的 存储 系统 有 AWS EBS 、GCE PD 、Azure 
Disk 或 Cinder。 动 态 创建 的 PV 资 源 的 回收 策略 取决 于 相关 存储 类 上 的 
定义 ， 存 储 类 上 相关 的 默认 策略 为 Delete， 大 多 数 情 况 下 ， 管 理 员 都 
以 免 导 致 数据 非 计 划 内 
9 误 删除 。 


4. 扩 展 PVC 


Kubernetes 自 1.8 版 本 起 增加 了 扩展 PV 空间 的 特性 ， 截 至 目前 ， 它 
所 支持 的 扩展 PVC 机 制 的 存储 卷 共 有 以 下 儿 种 。 


‘gcePersistentDisk 
‘awsElasticBlockStore 
Cinder 

‘glusterfs 


‘rbd 


“PersistentVolumeClaimResize” 准 入 插件 负责 对 支持 空间 大 小 变动 
的 存储 卷 执 行 更 多 的 验证 操作 ， 管 理 员 需要 事先 启用 此 插件 才能 使 用 
PVC 扩 展 机 制 ， 那 些 将 “allowVolume Expansion” 字 上 段 的 值 设 置 
为 “true” 的 存储 类 即 可 动态 扩展 存储 卷 空 间 。 随 后 ， 用 户 改 动 Claim 请 
求 更 大 的 空间 即 能 触发 底层 PV 空间 扩展 从 而 带 来 PVC 存 储 卷 的 扩展 。 


对 于 包含 文件 系统 的 存储 卷 来 说 ， 只 有 在 有 新 的 Pod 资 源 基 于 读 
写 模 式 开 始 使 用 PVC 时 才 会 执行 文件 系统 的 大 小 调整 操作 。 换 句 话 
说 ， 如 果 某 被 扩展 的 存储 卷 已 经 由 Pod 资 源 所 使 用 ， 则 需要 重建 此 Pod 
对 象 才能 触发 文件 系统 大 小 的 调整 操作 。 支 持 空 间 调 整 的 文件 系统 仅 
有 XFS 和 EXT3/EXT4。 


7.6” ”downwardAPI 存 储 卷 


很 多 时 候 ， 应 用 程序 需要 基于 其 所 在 的 环境 信息 设 定 运行 特性 
等 ， 这 类 环境 信息 包括 节点 及 集群 的 部 分 详细 属性 信息 等 ， 例 如 ， 
Nginx 进 程 可 根据 和 点 的 CPU 核心 数量 目 动 设 定 要 局 动 的 workerj 进 程 
数 ，JVM 虚 拟 机 可 根据 和 点 内 存 资源 目 动 设 定 其 堆 内 存 大 小 。 类 似 
地 ， 托 管 运 行 于 Kubernetes 的 Pod 对 象 中 的 容 姻 化 应 用 偶尔 也 需要 获取 
其 所 属 Pod 对 象 的 IP、 主 机 名 、 标 签 、 注 解 、UID、 请 求 的 CPU 及 内 存 
资源 量 及 其 限额 ， 甚 至 是 Pod 所 在 的 广 点 名 称 等 ， 容 器 可 以 通过 环境 
变量 或 downwardAPI 存 储 卷 访问 此 类 人 信息， 不过， 标签 和 注解 仪 支持 
通过 存储 卷 又 露 给 容器 。 


7.6.1 “环境 变量 式 元 数据 注入 


引用 downwardAPI 元 数据 信息 的 常用 方式 之 一 是 使 用 容 絮 的 环境 
变量 ， 它 通过 在 valueFrom 字 段 中 藤 套 fieldRef 或 resourceFieldRef 字 段 来 
引用 相应 的 数据 源 。 不 过 ， 通 常 只 有 常量 类 的 属性 才能 够 通过 环境 变 
量 注入 到 容 姻 中 ， 毕 竟 ， 在 进程 启动 完成 后 将 无 法 再 向 其 告知 变量 值 
的 变动 ， 于 是 ， 环 境 变 量 也 就 不 支持 中 途 的 更 新 操作 。 


可 通过 fieldRef 字 段 引 用 的 信息 具体 如 下 。 


:spec.nodeName: 节点 名 称 。 

status.hostIP: 六 点 IP 地 址 。 

:metadata.name: Pod 对 象 的 名 称 。 
.metadata.namespace: Pod 对 象 隶属 的 名 称 空 间 。 
status.podIP: Pod 对 象 的 IP 地 址 。 


.Spec.ServiceAccountName: Pod 对 象 使 用 的 ServiceAccount 资 源 的 
名 称 。 


:metadata.uid: Pod 对 象 的 UID。 


-metadata.labels['<KEY>'] : Pod 对 象 标签 中 的 指定 键 的 值 ， 例 如 
metadata.labels[mylabel]， 仅 Kubernetes 1.9 及 之 后 的 版 本 才 支 持 。 


-metadata.annotations['<KEY>'] : Pod 对 象 注解 信息 中 的 指定 键 的 
值 ， 仅 Kubernetes 1.9 及 之 后 的 版 本 才 支 持 。 


另外 ， 可 通过 resourceFieldRef 字 段 引 用 的 信息 是 指 当 前 容 妖 的 资 
源 请 求 及 资源 限额 的 定义 ， 因 此 它们 包括 requests.cpu 、limits.cpu 、 
requests.memory 和 limits.memory 四 项 。 


下 面 的 资源 配置 清单 示例 (downwardAPI-env.yaml) 中 定义 的 Pod 
对 象 通过 环境 变量 向 容器 env-test-container 中 注入 了 了 Pod 对象 的 名 称 、 


隶属 的 名 称 空 间 、 标 签 app 的 值 以 及 容器 目 身 的 CPU 资 源 限额 和 内 存 次 
源 请 求 等 信息 : 


apiVersion: v1 
kind: Pod 
metadata: 
name: env-test-pod 
labels: 
app: env-test-pod 
spec: 
containers: 
- name: env-test-container 
image: busybox 
command: [ "/bin/sh", "-c", "env" | 
resources: 
requests: 
memory: "32Mi" 
cpu: "125m" 
limits: 
memory: "64Mi" 
cpu: "250m" 
env: 
- name: MY_POD_NAME 
ValueFrom : 
fieldRef: 
fieldPath: metadata.name 
- Name: MY_POD_NAMESPACE 
valueFrom: 
fieldRef: 
fieldPath: metadata.namespace 
- Name: MY_APP_LABEL 
valueFrom: 
fieldRef: 
fieldPath: metadata.labels['app'] 
- name: MY_CPU_LIMIT 
ValueFrom : 
resourceFieldRef: 
resource: limits,.cpu 
- Name: MY_MEM_ REQUEST 
valueFrom: 
resourceFieldRef: 
resource: requests ,memory 
divisor: 1Mi 
restartPolicy: Never 


”此 Pod 对 象 创建 完成 后 ， 0 的 环境 变量 即 可 终止 
运行 ， 它 仅 用 于 测试 通过 环境 变量 注入 信息 到 容 句 的 使 用 效 末 : 


~]$ kubectl1 create -f downwardAPI-env.yaml 

pod "env-test-pod" created 

$ kubectl1 get pods -1 app=env-test-pod 

NAME READY STATUS RESTARTS AGE 
env-test-pod 0/1 Completed 0 1m 


而 后 即 可 通过 控制 台 日 志 获 取 注 入 的 环境 变量 : 


~]$ kubectl1 logs env-test-pod | grep "^MY_" 
MY_POD_NAMESPACE=default 

MY_CPU_LIMIT=1 

MY_APP_LABEL=env-test-pod 
MY_MEM_REQUEST=32 

MY_POD_NAME=env-test-pod 


如 示例 中 的 最 后 一 个 环境 变量 所 示 ， 在 定义 资源 请 求 或 资源 限制 
时 还 可 额外 指定 一 个 “divisor”* 字 段 ， 用 于 为 引用 的 值 指定 一 个 除数 以 
实现 所 引用 的 相关 值 的 单位 换算 。CPU 资 源 的 divisor 字 段 其 默认 值 为 
1， 表 示 为 1 个 核心 ， 相 除 的 结果 不 足 1 个 单位 时 则 同上 圆 整 (例如 ， 
0.25 癌 上 贺 整 的 结果 为 1) ， 它 的 另 一 个 可 用 单位 为 Im， 即 表示 1 个 微 
核心 。 内 存 资源 的 divisor 字 段 其 默认 值 为 也 是 1， 不 过 ， 它 意 指 1 个 字 
节 ， 此 时 ，32Mi 的 内 存 资源 则 要 换算 为 33554432 的 结果 了 予以 输出 。 其 
他 可 用 的 单位 还 有 1Ki、1Mi、1Gi 等 ， 于 是 ， 在 将 divisor 字 上 段 的 值 设置 
为 1Mi 时 ，32Mi 的 内 存 资源 的 换算 结果 即 为 32。 


fA 
>》 注意 “未 为 容器 定义 资源 请 求 及 资源 限额 时 ，downwardAPI 
引用 的 值 即 默认 为 节点 的 可 分 配 CPU 及 内 存 资源 量 。 


7.6.2 ”存储 卷 式 元 数据 注入 


回 容 需 注入 元 数据 信息 的 另 一 种 方式 是 使 用 downwardAPI 存 储 
卷 ， 它 将 配置 的 字段 数据 映射 为 文件 并 可 通过 容 需 中 的 挂 载 点 进行 访 
问 。7.2.5 方 中 能 够 通过 环境 变量 的 方式 注入 的 元 数据 信息 也 都 可 以 使 
用 存储 卷 的 方式 进行 信息 暴露 ， 除 此 之 外 ， 还 可 以 在 downwardAPI 存 
储 卷 中 使 用 fieldRef 引 用 如 下 两 个 数据 源 。 


.metadata.labels: Pod 对 象 的 所 有 标签 信息 ， 每 行 一 个 ， 格 式 为 
label-key="escaped-label-value" ° 


:metadata.annotations: Pod 对 象 的 所 有 注解 信息 ， 每 行 一 个 ， 格 式 


为 annotation-key="escaped-annotation-value"。 


下 面 的 资源 配置 清单 示例 (downwardAPI-vol.yaml) 中 定义 的 Pod 
对 象 通过 downwardAPI 存 储 卷 问 容 屁 Volume-test-container 中 注入 了 Pod 
对 象 隶 属 的 名 称 空间 、 标 签 、 注 解 以 及 容器 目 身 的 CPU 资 源 限额 和 内 
存 资 源 请 求 等 信息 。 存 储 卷 在 容 强 中 的 挂 载 点 为 /etc/podinfo 目 隶 ， 
此 ， 注 入 的 每 一 项 信息 均 会 映射 为 此 路 径 下 的 一 个 文件 : 


kind: Pod 
apiVersion: v1 
metadata: 
labels: 
zone: east-china 
rack: rack-101 
app: dapi-vol-pod 
name: dapi-vol-pod 
annotations: 
annotation1: "test-value-1" 
spec: 
containers: 
- Name: volume-test-container 
image: busybox 
command: ["sh", "-c", "sleep 864000"] 
resources: 
requests: 
memory: "32Mi" 
cpu: "125m" 
limits: 
memory: "64Mi" 
cpu: "250m" 
volumeMounts: 
- name: podinfo 
mountPath: /etc/podinfo 


readonly: false 
volumes: 
- name: podinfo 
downwardAPI: 
defaultMode: 420 
items: 
- fieldRef: 
fieldPath: metadata.namespace 
path: pod_namespace 
- fieldRef: 
fieldPath: metadata.1labels 
path: pod_labels 
- fieldRef: 
fieldPath: metadata.annotations 
path: pod_annotations 
- resourceFieldRef: 
containerName: volume-test-container 
resource: limits,.cpu 
path: "cpu_limit" 
- resourceFieldRef: 
containerName: volume-test-container 
resource: requests.memory 
divisor: "1Mi" 
path: "mem_request" 


创建 资源 配置 清单 中 定义 的 Pod 对 象 后 即 可 测试 访问 由 
downwardAPI 存 储 卷 映 射 的 文件 pod_namespace、pod_labels、 
pod_annotations、 limits_cpu 和 mem_request 等 : 


~]$ kubectl1 create -f downwardAPI-vol.yaml 
pod "dapi-vol-pod" created 


Re 0 例如 ， 查 看 Pod 对 象 的 标 
签 列表 : 


~]$ kubectl1 exec dapi-vol-pod -- cat /etc/podinfo/pod_labels 
app="dapi-vol-pod" 

rack="rack-101" 

zone="east-china" 


如 命令 结果 所 示 ，Pod 对 象 的 标签 信息 每 行 一 个 地 映射 于 目 定 义 
的 路 径 /etcpodinfo/pod_labels 文 件 中 ， 关 似 地 ， 注解 信息 也 以 这 种 方式 
进行 处 理 。 如 前 面 的 章节 中 所 述 ， 标 答 和 注解 文 持 运行 时 修改 ， 其 改 
动 的 结果 也 会 实时 映射 进 downwardAPI 生 成 的 文件 中 。 例 如 ， 为 dapi- 
vol-pod 添 加 新 的 标签 


~]$ kubectl1 label pods dapi-vol-pod env="test" 
pod "dapi-vol-pod" labeled 


而 后 再 次 查看 容器 内 的 pod_labels 文 件 的 内 容 ， 由 如 下 的 命令 结果 
可 知 新 的 标签 已 经 能 够 通过 相关 的 文件 获取 到 |: 


~]$ kubectl1 exec dapi-vol-pod -- cat /etc/podinfo/pod_labels 
app="dapi-vol-pod" 

env="test" 

rack="rack-101" 

zone="east-china" 


downwardAPI 存 储 卷 为 Kubernetes 上 运行 容器 化 应 用 提供 了 获取 外 
部 环境 信息 的 有 效 途 径 ， 这 一 点 对 那些 非 为 云 原生 开发 的 应 用 程序 在 
四 代码 重 构 的 前 提 下 ， 获 取 环 境 信息 进行 目 身 配置 等 操作 时 尤为 


7.7 本 章 小 结 


本 章 主要 讲解 了 Kubernetes 的 存储 卷 及 其 功用 ， 并 通过 应 用 示例 
给 出 了 部 署 存储 卷 类 型 的 使 用 方法 ， 有 具体 如 下 。 


.临时 存储 卷 emptyDir 和 gitRepo 的 生命 周期 与 Pod 对 象 相同 ， 但 
gitRepo 能 够 通过 引用 外 部 Git 仓 库 的 数据 来 实现 数据 的 持久 性 。 


万 点 存储 卷 hostPath 提 供 了 克 点 级 别 的 数据 持久 能 


:网 络 存储 卷 NFS、GlusterFS 和 RBD 等 是 企业 内 部 较为 常用 的 独立 
部 署 的 持久 存储 系统 。 


: 云 存储 卷 AWS ebs 等 是 托管 于 云端 的 Kubernetes 系 统 上 较为 第 用 的 
持久 存储 系统 。 


.PV 和 PVC 可 将 存储 管理 和 存储 使 用 解 籼 为 消费 者 模型 。 


:基于 StorageClass 可 以 实现 PV 的 动态 供给 ，GlusterFS 和 Ceph 
RBD， 以 及 云端 存储 AWS ebs 等 都 可 以 实现 此 类 功能 。 


第 8 章 ”配置 容 絮 应 用 : ConfigMap 和 Secret 


ConfigMap 和 Secret 是 Kubernetes 系 统 上 两 种 特殊 类 型 的 存储 卷 ， 
ConfigMap 对 象 用 于 为 容 右 中 的 应 用 提供 配置 数据 以 定制 程序 的 行 
为 ， 不 过 敏感 的 配置 信息 ， 例 如 密 钥 、 证 书 等 通常 由 Secret 对 象 来 进行 
配置 。 它 们 将 相应 的 配置 信息 保存 于 对 象 中 ， 而 后 在 Pod 资 源 上 以 存 
储 卷 的 形式 将 其 挂 载 并 获取 相关 的 配置 ， 以 实现 配置 与 镜像 文件 的 解 
耦 。 本 章 将 主要 讲解 ConfigMap 与 Secret 存 储 卷 的 用 法 。 


8.1 容 絮 化 应 用 配置 方式 


每 个 应 用 程序 都 是 一 个 可 执行 程序 文件 ， 它 包含 操作 码 列 表 ， 
CPU 通 过 执行 这 些 操作 码 来 完成 特定 的 操作 。 例 如 ，cat 命 令 是 
由 /usr/bin/cat 文 件 提 供 的 ， 该 文件 舍 有 机 器 指 令 的 列表 ， 在 屏幕 上 显示 
指定 文件 的 内 容 时 需要 使 用 这 些 机 如 指令 。 几 乎 每 个 程序 的 行为 都 可 
以 通过 其 命令 行 选 项 及 参数 或 配置 文件 来 按 需 定制 。 实 践 中 ， 人 们 通 
常 不 会 以 默认 的 配置 参数 运行 应 用 程序 ， 而 是 需要 根据 特定 的 环境 或 
具体 的 需求 定制 其 运行 特性 ， 对 于 复杂 的 服务 类 应 用 程序 更 是 如 此 ， 
如 Nginx、Tomcat 和 HBase 等 ， 而 且 通 过 配置 文件 定义 其 配置 通常 是 首 
选 甚至 是 唯一 的 途径 。 


那么 ， 如 何 为 容 需 中 的 应 用 提供 配置 信息 呢 ? 例如 ， 为 Nginx 配 置 
一 个 特定 Server 或 指定 worker 进 程 的 数量 ， 为 Tomcat 的 JVM 配 置 其 堆 内 
存 的 大 小 等 。 传 统 实践 中 ， 通 常 有 这 么 几 种 途径 : 启动 容 絮 时 直接 癌 
命令 传递 参数 、 将 定义 好 的 配置 文件 硬 编码 于 〈 舱 入 ) 镜像 文件 中 、 
通过 环境 变量 (Environment Variables) 传递 配置 数据 ， 以 及 基于 
Docker 卷 传送 配置 文件 等 。 


1. 通 过 命令 行 参数 进行 配置 


Docker 容 器 可 用 来 运行 单个 应 用 程序 。 在 制作 Docker 镜 像 时 ， 
Dockerfile 中 的 ENTRYPOINT 和 CMD 指 令 可 用 于 指定 容器 启动 时 要 运 
行 的 程序 及 其 相关 的 参数 。CMD 指 令 以 列表 的 形式 指定 要 运行 的 程序 
及 其 相关 的 参数 ， 但 若 同 时 存在 ENTRYPOINT 指 令 ， 则 CMD 指 令 中 列 
表 的 所 有 元 素 均 将 被 视 作 是 由 ENTRYPOINT 指 定 的 程序 的 命令 行 参 
数 。 另 外 ， 在 基于 某 镜像 使 用 Docker 命 令 创 建 容器 时 ， 可 以 在 命令 行 
可 ENTRYPOINT 中 的 程序 传递 额外 的 自 定义 参数 ， 甚 至 还 可 以 修改 要 
运行 的 应 用 程序 本 丑 ° 例如， 使 用 docker run 命 令 创 建 并 启动 容器 的 格 


a 


docker run[OPTIONS]IMAGE[COMMAND] [ARG...] 


其 中 的 [COMMAND] 即 为 自 定义 运行 的 程序 ，[ARG] 则 是 传递 给 
程序 的 参数 。 若 定义 相关 的 镜像 文件 时 使 用 了 ENTRYPOINT 指 令 ， 则 


[COMMAND] 和 [ARG] 都 会 被 当 作 命令 行 参 数 传 递 给 ENTRYPOINT 指 

令 中 指定 的 程序 ， 除 非 为 docker run 命 令 额外 使 用 --entrypoint 选 项 覆盖 

。 相 关 的 使 用 详情 请 参考 Docker 的 
日 关 教 程 。 


在 Kubernetes 系 统 上 创建 Pod 资 源 时 ， 也 能 够 癌 容 厚 化 应 用 传递 命 
令 行 参数 ， 长 至 指定 运行 其 他 应 用 程序 ， 相 关 的 字段 分 别 为 邮 
pods.spec.containers.command 和 pods.spec.containers.args。 这 一 点 在 前 


面相 关 的 章节 中 已 有 相关 的 使 用 说 明 。 
2. 将 配置 文件 散 入 镜像 文件 


所 谓 的 将 配置 文件 租 入 镜像 文件 ， 是 指 用 户 在 Dockerfile 中 使 用 
COPY 指 令 把 定义 好 的 配置 文件 复制 到 镜像 文件 系统 上 的 目标 位 置 ， 
或 者 使 用 RUN 指 令 调 用 sed 或 echo 一 类 的 命令 修改 配置 文件 从 而 达到 为 
容 如 化 应 用 提供 目 定 义 配 置 文件 之 目的 。 使 用 时 ， 铬 Docker Hub 上 的 
某 镜像 文件 额外 添加 配置 文件 即 能 符合 需要 ， 则 克隆 其 Dockerfile 文 件 
修改 至 符合 需求 之 后 再 将 之 推送 至 GitHub， 并 由 Docker Hub 上 自动 构建 
出 镜像 文件 即 可 。 


这 种 方式 的 优势 在 于 对 于 用 户 来 说 简单 易 用 ， 不 用 任何 额外 的 设 
定 束 能 局 动 符合 需求 的 容器 ， 用 于 Kubernetes 环 境 亦 无 须 多 余 的 配 
置 。 但 配置 文件 相关 的 任何 额外 的 修改 需求 都 不 得 不 通过 重新 构建 镜 
人 


3. 通 过 环境 变量 向 容 右 注入 配置 信息 


通过 环境 变量 为 镜像 提供 配置 信息 是 Docker Hub 上 最 常见 的 使 用 
方式 。 例 如 ， 使 用 MySQL 官 方 提供 的 镜像 文件 启动 MySQL 容 器 时 使 
用 的 MYSQL_ROOT_PASSWORD 环 境 变 量 ， 它 用 于 为 MySQL 服 务 器 
的 root 用 户 设置 登录 密码 。 


在 基于 此 类 镜像 启动 容器 时 ， 用 户 为 docker run 命 令 通 过 -e 选 项 问 
环境 变量 传 值 即 能 实现 应 用 配置 ， 命 令 的 使 用 格式 为 “docker run-e 
SETTING1=foo-e SETTING2=bar...<image name>”。 启动 时 ， 容 器 的 
ENTRYPOINT 启 动 脚本 会 抓 取 到 这 些 环境 变量 ， 并 在 启动 容器 应 用 之 
前 ， 通 过 sed 或 echo 等 一 类 的 命令 将 变量 值 蔡 换 到 配置 文件 中 。 


一 般 说 来 ， 容 器 的 ENTRYPOINT 脚 本 应 该 为 这 些 环 境 变 量 提供 默 
认 值 ， 以 便 在 用 户 未 为 环境 变量 传 值 时 也 能 基于 此 类 需要 环境 变量 的 
镜像 启动 容 丹 。 使 用 环境 变量 这 种 配置 方式 的 优势 在 于 配置 信息 的 动 
态 化 供给 ， 不 过 ， 有 些 应 用 程序 的 配置 可 能 会 复杂 到 无 法 通过 
key/value 格 式 的 环境 变量 完成 。 


另外 ， 也 可 以 让 容器 的 ENTRYPOINT 启 动 脚 本 通过 网 络 中 的 K/V 
存储 获取 配置 参数 ， 常 用 的 此 类 存储 系统 有 Consul 或 etcd 等 。 这 种 方式 
较 之 简单 的 环境 变量 能 够 提供 更 复杂 的 配置 信息 ， 因 为 KV 存储 系统 
持 多 层级 的 山 套 数据 结构 ， 有 一 些 应 用 广泛 的 数据 抓 取 工具 能 够 从 KV 
存储 中 加 载 相 关 的 数据 并 替换 于 配置 文件 中 ， 其 至 于 像 confd 这 类 的 工 
有 具 还 能 在 KV 中 的 数据 变化 时 自动 将 其 重 载 至 配置 文件 中 ， 这 一 点 实现 
了 真正 意义 上 的 配置 动态 化 。 不 过 ， 这 种 方式 为 容器 化 应 用 引入 了 额 
外 的 依赖 条 件 。 


Kubernetes 系 统 支 持 在 为 Pod 资 源 配 置 容器 时 使 用 
spec.containers.env 为 容 絮 的 环境 变量 传 值 从 而 完成 应 用 的 配置 。 如 前 
1 ee 配置 场景 ， 因 此 提供 的 配置 能 力也 
不 o 


4. 通 过 存储 卷 癌 容 需 注入 配置 信息 


Docker 存 储 卷 “volumes) 能 够 将 宿主 机 之 上 的 任何 文件 或 日 录 映 
射 到 容器 文件 系统 上 ， 因 此 ， 可 以 事先 将 配置 文件 放置 于 和 窒 主机 之 上 
的 某 特定 路 径 中 ， 而 后 在 局 动容 器 时 进行 加 载 。 这 种 方式 灵活 易 用 ， 
但 也 依赖 于 用 户 需 要 事先 将 配置 数据 提供 在 答 主 机 上 的 特定 路 人 径 下 ， 
而 且 在 多 主机 模型 中 ， 若 容 絮 存在 被 调度 至 任 一 主机 运行 的 可 能 性 
EA 
它们。 


5. 借 助 Docker config 进 行 容器 配置 


Docker swarm service 自 1.13 版 本 起 支持 使 用 secret 于 容器 之 外 保存 
二 进 制 数据 ， 包 括 口令 、SSH 私 铀 、SSL 证 书 以 及 其 他 不 建议 通过 网 
络 传输 或 不 应 该 在 Dockerfile 及 程序 源码 中 非 加 密 保 存 的 机 密 数 据 。 用 
户 可 使 用 secret 集 中 化 管理 这 类 数据 并 将 其 安全 关联 至 那些 需要 访问 这 
些 数 据 的 容器 中 。 


另外，Docker 自 17.06 版 本 起 为 swarm service 引入 了 人 允许 用 户 于 容 
器 之 外 存储 非 人 敏感 信息 (如 配置 文件 ) 的 组 件 “service config”， 从 而 文 
持 用 户 创 建 通 用 目的 镜像 文件 ， 并 且 不 再 需要 通过 挂 载 存 储 卷 或 使 用 
环境 变量 为 容 右 提供 配置 文件 。 


Docker swarm service secret 和 config 为 容 名 化 应 用 的 配置 提供 了 极 
大 的 灵活 性 ， 不 过 ， 它 们 也 只 能 应 用 于 Docker swarm service 环 境 中 ， 
而 不 能 应 用 于 单独 运行 的 容器 之 上 。 


Kubermnetes 系 统 也 有 类 似 的 组 件 ， 它们 称 为 Secret 和 ConfigMap， 
而 且 是 Kubernetes 系 统 上 一 等 类 别 的 资源 对 象 ， 它 们 要 么 被 Pod 资 源 以 
ee 要 么 由 容器 通过 envEFrom 字 段 以 变 量 的 形式 加 
车 O 


8.2 ”通过 命令 行 参数 配置 容 郁 应 用 


创建 Pod 资 源 时 ， 可 以 在 容器 定义 中 自 定义 要 运行 的 命令 以 及 为 其 
传递 的 选项 和 参数 。 在 容 絮 的 配置 上 下 文中 ， 使 用 command 字 段 指定 
要 运行 的 程序 ， 而 args 字 段 则 可 用 于 指定 传递 给 程序 的 选项 及 参数 。 在 
配置 文件 中 定义 的 command 和 args 会 履 盖 镜像 文件 中 相关 的 默认 设 定 ， 
这 类 程序 会 被 直接 运行 ， 而 不 会 由 shell 解 释 器 解释 运行 ， 因 此 与 shell 相 
天 的 特性 均 不 被 文 持 ， 如 命令 行 展开 符号 {}、 重 定 癌 等 操作 。 

下 面 是 定义 在 command-demo.yaml 文 件 中 的 Pod 资 源 示 例 ， 它 在 容 


右 command-demo-container 中 将 busybox 镜 像 文件 中 默认 运行 的 命令 
["/bin/sh" ， "_c"] 修 改 为 ["httpd"] ， 并 为 其 额外 传递 了 ["-f"] 选 项 


apiVersion: v1 
kind: Pod 
metadata: 
name: command-demo 
labels: 
purpose: demonstrate-command 
spec: 
containers: 
- name:; command-demo-container 
image: busybox 
command: ["httpd"] 
args: ["-f"] 
ports: 
- containerPort: 80 
restartPolicy: OnFailure 


事实 上 ， 用 户 也 可 以 只 在 容器 配置 的 上 下 文中 提供 args 字 段 ， 以 实 
现 向 默认 运行 的 程序 提供 额外 的 参数 。 如 果 默 认 的 命令 为 Shell 解 释 器 
或 entrypoint 启 动 脚本 ， 那 么 这 些 参数 本 身 甚至 还 可 以 是 要 运行 的 命令 
及 其 参数 。 例 如 ， 下 面 的 容器 配置 ， 表 示 要 运行 的 程序 为“/bin/sh-c 
httpd-f”， 实 现 了 以 shell 解 释 器 解释 运行 指定 的 程序 之 目的 


spec: 
containers: 
- name: command-demo-container 
image: busybox 
args: ["httpd", "-f"] 
ports: 
- containerPort: 80 


由 上 未 的 应 用 示例 可 见 ，Kubernetes 配 置 文件 中 的 command 对 应 于 
Dockerfile 中 的 ENTRYPOINT， 而 配置 文件 中 的 args 则 对 应 于 Dockerfile 
中 的 CMD。 在 Kubernetes 中 只 给 出 command 字 段 时 ， 它 会 覆盖 
Dockerfile 中 的 ENTRYPOINT 和 CMD， 只 给 出 args 字 段 时 ， 它 仅 有 覆 盖 
CMD， 而 同时 给 出 command 和 args 时 ， 会 对 应 覆盖 ENTRYPOINT 和 
CMD。 其 应 用 生效 的 示例 如 图 8-1 所 示 。 


通过 命令 行 参数 的 方式 癌 容 器 应 用 传递 配置 数据 的 操作 比较 简 
单 ， 但 其 功能 有 限 ， 难 以 为 应 用 生成 复杂 配置 ， 尤 其 是 那些 不 支持 通 
过 命令 行 参数 进行 的 配置 将 无 法 基于 这 种 机 制 来 实现 。 另 外 需要 注意 
的 是 ， 在 容器 创建 完成 后 ， 修 改 command 和 args 并 不 会 直接 生效 ， 除 非 
重建 Pod 对 象 。 


Image Entrypoint Image Cmd Container command Container args Command run 
[/ep-1] [foo bar] <not set> <not set> [ep-1 foo bar] 
[/ep-1] [foo bar] [/ep-2] <not set> [ep-2] 

[/ep-1] [foo bar] <not set> [zoo boo] [ep-1 zoo boo] 
[/ep-1] [foo bar] [/ep-2] [zoo boo] [ep-2 zoo boo] 


图 8-1 command/args 和 ENTRYPOINT/CMD 


8.3 利用 环境 变量 配置 容 需 应 用 


于 运行 时 配置 Docker 容 器 中 应 用 程序 的 第 二 种 方式 是 在 容器 启动 
时 向 其 传递 环境 变量 。Docker 原 生 的 应 用 程序 应 该 使 用 很 小 的 配置 文 
件 ， 并 且 每 一 项 参数 都 可 由 环境 变量 或 命令 行 选项 覆盖 ， 从 而 能 够 在 
运行 时 完成 任意 的 按 需 配 置 。 然 而 ， 目 前 只 有 极 少 一 部 分 应 用 程序 为 
容器 环境 原生 设计 ， 毕 竟 为 容器 原生 重 构 应 用 程序 工程 浩大 ， 且 上 旷 日 
持久 。 好 在 有 通过 容器 启动 脚本 为 应 用 程序 预 设 运行 环境 的 方法 可 
用 ， 通 行 的 做 法 是 在 制作 Docker 镜 像 时 ， 为 ENTRYPOINT 指 令 定 义 一 
个 脚本 ， 它 能 够 在 启动 容器 时 将 环境 变量 替换 至 应 用 程序 的 配置 文件 
中 ， 而 后 再 由 此 脚本 启动 相应 的 应 用 程序 。 基 于 这 类 镜像 运行 容器 
时 ， 即 可 通过 向 环境 变量 传 值 的 方式 来 配置 应 用 程序 。 


在 Kubernetes 中 使 用 此 类 镜像 局 动容 右 时 ， 也 可 以 在 Pod 资 源 或 
Pod 模 板 资 源 的 定义 中 ， 为 容器 配置 段 使 用 env 参 数 来 定义 所 使 用 的 环 
境 变 量 列表 。 事 实 上 ， 即 便 容 妖 中 的 应 用 本 身 不 处 理 环 境 变 量 ， 也 一 
样 可 以 同 容器 传递 环境 变量 ， 只 不 过 它 不 被 使 用 轻 了 。 


环境 变量 配置 容 右 化 应 用 时 ， 需 要 在 容 紫 配置 段 中 柳 套 使 用 env 子 
段 ， 它 的 值 是 一 个 由 环境 变量 构建 的 列表 。 环 境 变 量 通 前 由 name 和 


value (或 valueFrom) 字段 构成 。 
name<string> : 环境 变量 的 名 称 ， 必 选 字 段 。 


value<string> : 环境 变量 的 值 ， 通 过 $ (VAR_NAME) 引用 ， 逃 
人 选 格式 为 “<$$ (VAR_NAME) ”， 默 认 值 为 空 。 


:ValueFrom<Object>: 环境 变量 值 的 引用 源 ， 例 如 ， 当 前 Pod 资 源 
的 名 称 、 名 称 空 间 、 标 签 等 ， 不 能 与 非 空 值 的 value 字 段 同时 使 用 ， 即 
环境 变量 的 值 要 么 源 于 value 字 段 ， 要 么 源 于 valueFrom 字 段 ， 二 者 不 可 
同时 提供 数据 。 


valueFrom 字 段 可 引用 的 值 有 多 种 来 源 ， 包 括 当 前 Pod 资 源 的 属性 
值 ， 容 器 相关 的 系统 资源 配置 、ConfigMap 对 象 中 的 Key 以 及 Secret 对 
象 中 的 Key， 它 们 应 分 别 使 用 不 同 的 般 套 字段 进行 定义 。 


fieldRef<Object> : 当前 Pod 资 源 的 指定 字段 ， 目 前 文 持 使 用 的 字 
段 包括 metadata.name 、metadata.namespace、metadata.labels、 
metadata.annotations 、 spec.nodeName 、spec.serviceAccountName 、 
status.hostIP 和 status.podIP ° 


:configMapKeyRef<Object> : ConfigMap 对 象 中 的 特定 Key。 
“secretKeyRef<Object> : Secret 对 象 中 的 特定 Key。 


resourceFieldRef<Object> : 当前 容 絮 的 特定 系统 资源 的 最 小 值 
(配额 ， 或 最 大 值 (限额 ， 目 前 支持 的 引用 包括 limits.cpu 、 
limits.memory 、 limits.ephemeral-storage 、 requests.cpu 、 
requests.memory 和 requests.ephemeral-storage ° 


下 面 是 定义 在 配置 文件 env-demo.yaml 中 的 Pod 资 源 ， 其 通过 环境 
变量 引用 当前 Pod 资 源 及 其 所 在 的 节点 的 相关 属性 值 配置 容 丹 。 
fieldRef 字 段 的 值 是 一 个 对 象 ， 它 一 般 由 apiVersion (创建 当前 Pod 资 源 
的 API 版 本 ) 或 fieldPath 航 套 字 段 所 定义 : 


apiVersion: v1 
kind: Pod 
metadata: 
name: env-demo 
labels: 
purpose: demonstrate-environment-variables 
spec: 
containers: 
- Name: env-demo-container 
image: busybox 
command: ["httpd"] 
args: ["-f"] 
env: 
- name: HELLO_WORLD 
value: just a demo 
- Name: MY_NODE_NAME 
valueFrom: 
fieldRef: 
fieldPath: spec.nodeName 
- Name: MY_NODE_IP 
valueFrom: 
fieldRef: 
fieldPath: status.hostIP 
- Name: MY_POD_NAMESPACE 
valueFrom: 
fieldRef: 
fieldPath: metadata.namespace 
restartPolicy: OnFailure 


创建 上 面 资 源 清单 中 定义 的 Pod 对 象 env-demo， 而 后 打印 它 的 环 
境 变量 列表 、 命 令 及 其 结 采 如 下 : 


~]$ kubect1 exec env-demo printenv 
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin 
HOSTNAME=env-demo 

MY_NODE_NAME=node02.ilinux.io 

MY_NODE_IP=172.16.0.67 

MY_POD_NAMESPACE=default 

HELLO_WORLD=just a demo 


容 絮 的 启动 脚本 或 应 用 程序 调用 或 处 理 这 些 环 境 变 量 ， 即 可 实现 
容 絮 化 应 用 的 配置 。 相 较 于 命令 行 参数 的 方式 来 说 ， 使 用 环境 变量 的 
配置 方式 更 清晰 、 昂 懂 ， 尤 其 是 对 于 首次 使 用 相关 容器 的 用 户 来 说 ， 
这 种 方式 能 够 快速 了 解 容器 的 配置 方式 。 不 过 ， 这 两 种 配置 方式 有 一 
个 共同 的 缺陷 ， 无 法 在 容器 应 用 运行 过 程 中 更 新 环境 变量 从 而 达到 更 
新 应 用 之 目的 。 这 通常 意味 着 用 户 不 得 不 为 production、development 和 
同 的 环境 分 别 配置 Pod 资 源 。 好 在 ， 用 户 还 有 ConfigMap 资 源 可 


8.4 应 用 程序 配置 管理 及 ConfigMap 资 源 


分 布 式 环境 中 ， 基 于 人 负载、 容错 等 需求 的 考虑 ， 儿 乎 所 有 的 服务 
都 需要 在 不 同 的 机 融 世 点 上 部 署 不 止 一 个 实例 。 随 痢 程 序 功能 的 日 花 
复杂 ， 程 序 的 配置 日 益 增 多 ， 而 且 配置 文件 的 修改 频率 通 闻 远 远大 于 
代码 本 喘 ， 这 种 情况 下 ， 有 时 仅仅 是 一 个 配置 内 容 的 修改 ， 就 不 得 不 
重新 进行 代码 提交 到 SVIYVGit、 打 包 、 分 发 上 线 的 流程 。 部 署 规则 较 
大 的 场景 中 ， 分 发 上 线 工 作 既 繁杂 又 沉重 。 


究 其 根本 ， 所 有 的 这 些 麻 烦 都 是 由 于 配置 和 代码 在 管理 和 发 布 过 
程 中 不 加 区 分 所 致 。 配置 本 身 源 于 代码 ， 古 为 了 提高 代码 的 灵活 性 而 
提取 出 来 的 一 些 经 营 变 化 的 或 需要 定制 的 内 容 ， 而 正 古 配置 的 这 种 天 
生 的 变化 特征 为 部 著 过 程 市 来 了 不 小 的 麻烦 ， 也 最 终 催生 了 分 布 式 系 
统 配置 管理 系统 ， 将 配置 内 容 从 代码 中 完全 分 离 出 来 ， 及 时 可 靠 高 效 
地 提供 配置 访问 和 更 新 服务 。 


名 提示 “国内 分 布 式 配置 中 心 相关 的 开源 项 目 有 Diamond ( 阿 
里 ) 、Apollo (携程 、Qconf 〈 奇 虎 360) 和 disconf (百度 ) 等 。 


作为 分 布 式 系统 的 Kubernetes 也 提供 了 统一 配置 管理 方案 一 
ConfigMap。Kubernetes 基 于 ConfigMap 对 象 实 现 了 将 配置 文件 从 容器 
镜像 中 解 炸 ， 从 而 增强 了 容 狗 应 用 的 可 移植 性 。 人 简单 来 说 ， 一 个 
ConfigMap 对 和 象 就 是 一 系列 配置 数据 的 集合 ， 这 些 数据 可 “注入 ”到 Pod 
se ， 注 入 方式 有 挂 载 为 存储 卷 和 传递 为 环 
漠 变 量 


ConfigMap 对 和 象 将 配置 数据 以 键 值 对 的 形式 进行 存储 ， 这 些 数据 
可 以 在 Pod 对 象 中 使 用 或 者 为 系统 组 件 提供 配置 ， 例 如 控制 器 对 象 
等 。 不 过 ， 无 论 应 用 程序 如 何 使 用 ConfigMap 对 象 中 的 数据 ， 用 户 都 
完全 可 以 通过 在 不 同 的 环境 中 创建 名 称 相同 但 内 容 不 同 的 ConfigMap 
对 象 ， 从 而 为 不 同 环境 中 同一 功能 的 Pod 资 源 提供 不 同 的 配置 信息 ， 
实现 应 用 与 配置 的 灵活 勾 兄 。 


8.4.1 创建 ConfigMap 对 象 


Kubernetes 的 不 少 资源 既 可 以 使 用 kubectl create 命 令 创建 ， 也 可 以 
使 用 清单 创建 ， 例 如 前 面 讲 到 的 namespace。ConfigMap 是 另 一 个 两 种 
创建 方式 都 比较 常用 的 资源 。 而 且 ， 通 过 使 用 “kubectl create 
configmap” 命 令 ， 用 户 可 以 根据 目录 、 文 件 或 直接 值 创建 ConfigMap 对 
象 。 命 令 的 语法 格式 如 下 所 示 : 


kubect] create configmap<map-name><data-source> 


其 中 ，<map-name> 即 为 ConfigMap 对 象 的 名 称 ， 而 <data-source> 
是 数据 源 ， 它 可 以 通过 直接 值 、 文 件 或 目录 来 获取 。 无 论 是 哪 一 种 数 
据 源 供给 方式 ， 它 都 要 转换 为 ConfigMap 对 象 中 的 Key-Value 数 据 ， 其 
中 Key 由 用 户 在 命令 行 给 出 或 是 文件 数据 源 的 文件 名 ， 它 仅 能 由 字 
、 数字、 连接 号 和 点 号 组 成 ， 而 Value 则 是 直接 值 或 文件 数据 源 的 内 
容 。 


1. 利 用 直接 值 创建 


为 “kubectl create configmap” 命 令 使 用 “--from-literal" 选 项 可 在 命令 
行 直接 给 出 键 值 对 来 创建 ConfigMap 对 象 ， 重 复 使 用 此 选项 则 可 以 传 
递 多 个 键 什 对。 命令 格式 如 下 : 


kubectl create configmap configmap_name --from-literal=key-name-1=value-1 


例如 ， 下 面 的 命令 创建 special-config 时 传递 了 两 个 键 值 对 : 


~]$ kubectl1 create configmap Special-config \ 
--from-literal=special.how=very --from-literal=special.type=charm 


“get configmap” 命 令 可 用 于 查看 创建 的 ConfigMap 对 象 special- 
config 的 相关 信息 ， 例 如 ， 如 下 的 命令 及 其 结果 : 


$ kubectl1 get configmaps Special-config -0 yaml 
apiVersion: v1 
data: 
special.how: very 
special.type: charm 
kind: ConfigMap 
metadata: 
creationTimestamp: 2018-03-17T05:24:56Z 
name: special-config 
namespace: default 
resourceVersion: "465543" 
selfLink: /api/vi/namespaces/default/configmaps/special-config 
uid: 87b1bda2-29a3-11e8-b246-000c29be4e28 


此 类 方式 提供 的 数据 量 有 限 ， 一 般 是 在 仅 通 过 有 限 的 几 个 数据 项 
即 可 为 Pod 资 源 提供 足够 的 配置 信息 时 使 用 。 


2. 基 于 文件 创建 


为 “kubectl create configmap” 命 令 使 用 “--from-file” 选 项 即 可 基于 文 
件 内 容 来 创建 ConfigMap 对 象 ， 它 的 命令 格式 如 下 。 可 以 重复 多 次 使 
用 “--from-file” 选 项 以 传递 多 个 文件 内 容 : 


kubect] create configmap <configmap_name> --from-file=<path-to-file> 


例如 ， 下 面 的 命令 可 以 把 事先 准备 好 的 Nginx 配 置 文件 模板 保存 于 
ConfigMap 对 象 nginx-config 中 


~]$ kubectl1 create configmap nginx-config \ 
--from-file=./data/configs/nginx/conf.d/myserver.conf 


这 种 方式 创建 的 ConfigMap 对 象 ， 其 数据 存储 的 键 为 文件 路 径 的 
基 名 ， 值 为 文件 内 容 ， 例 如 下 面 命令 显示 的 nginx-config 对 象 的 信息 : 


~]$ kubectl1 get configmap nginx-config -0 yaml 
apiVersion: v1 
data: 
myserver.conf: | 
server { 
listen 8080; 
server_name www.ilinux.io,; 


include /etc/nginx/conf.d/myserver-*.cfg,; 


location /区 


root /usr/share/nginx/html; 


} 
kind: ConfigMap 


如 果 需 要 上 自行 指定 键 名 ， 则 可 在 “--from-file” 选 项 中 直接 指定 目 定 
义 的 键 ， 命 令 格式 如 下 : 


kubectl1 create configmap <configmap_name> --from-file= <my-key-name>=<path-to- 
file> 


通过 这 种 方式 创建 的 ConfigMap 资 源 可 以 直接 以 键 值 形式 收纳 应 
用 程序 的 完整 配置 信息 ， 多 个 文件 可 分 别 存储 于 不 同 的 键 值 当中 。 吨 
人 基于 直接 值 和 基于 文件 创建 的 方式 也 可 以 混 编 使 


3. 基 于 目录 创建 


如 来 配 置 文件 数量 较 多 且 存 储 于 有 限 的 目录 中 时 ，kubectl 还 提供 
了 基于 日 录 和 直接 将 多 个 文件 分 别 收 纳 为 键 值 数据 的 ConfigMap 资 源 创 
建 方式 。 将 “--from-file” 选 项 后 面 所 跟 的 路 径 指 向 一 个 目录 路 径 丈 能 将 
0 文件 一 同 创建 于 同一 ConfigMap 资 源 中 ， 命 令 格式 如 


kubect] create configmap <configmap_name> --from-file=<path-to-directory> 


如 下 面 的 命令 ， 将 /data/configs/nginx/conf.d/ 目 如 下 的 所 有 文件 都 
保存 于 nginx-config-files 对 象 中 : 


~]$ kubect1l create configmap nginx-config-files --from-file=./data/configs/ 
nginx/conf.d/ 


此 目录 中 包含 myserverconf、myserver-status.cfg 和 myserver- 
gzip.cfg 三 个 配置 文件 。 创 建 ConfigMap 资 源 时 ， 它 们 会 被 分 别 存 储 为 
三 个 键 值 数据 ， 如 下 面 的 命令 及 其 结 采 所 示 : 


~]$ kubect1 get cm nginx-config-files -0 yaml 
apiVersion: v1 
data: 
myserver-gzip.cfg: | 
gzip on; 
gzip_comp_level 5; 
gzip_proxied expired no-cache no-store private auth,; 
gzip_types text/plain text/css application/xml] text/javascript; 
myserver-status.cfg: | 
location /nginx-status { 
stub_status on; 
access_log off， 


myserver.conf: | 
server { 
listen 8080; 
server_name www.ilinux.io,; 


include /etc/nginx/conf.d/myserver-*.cfg; 


location / { 
root /usr/share/nginx/html; 
} 


} 
kind: ConfigMap 


注意 ，describe 命 令 和 get-o yaml 命 令 都 可 显示 由 文件 创建 而 成 的 
键 及 其 值 ， 不 过 两 者 使 用 的 键 和 值 之 间 的 分 隔 和 从 不 同 。 


4. 使 用 清单 创建 


基于 配置 文件 创建 ConfigMap 资 源 时 ， 它 所 使 用 的 字段 包括 通 
的 apiVersion、kind 和 metadata 字 段 ， 以 及 用 于 存储 数据 的 天 键 字 
段 “data”。 例 如 下 面 的 示例 代码 : 


apiVersion: v1 
kind: ConfigMap 
metadata.: 
name: configmap-demo 
namespace: default 
data: 
log_level: INFO 
log_file: /var/log/test.1og 


如 果 其 值 来 自 于 文件 内 容 时 ， 则 使 用 配置 文件 创建 ConfigMap 资 
源 的 便捷 性 还 不 如 直接 通过 命令 行 的 方式 ， 因 此 建议 直接 使 用 命令 行 
加 载 文件 或 目录 的 方式 进行 创建 。 为 了 便于 配置 留存 ， 可 以 在 创建 完 
成 后 使 用 get-o yaml 命 令 获取 到 相关 信息 后 再 进行 编辑 留存 。 


8.4.2” 癌 Pod 环 境 变量 传递 ConfigMap 对 象 键 值 数 
据 


如 8.3 节 中 所 描述 的 ，Pod 资 源 的 环境 变量 值 的 获得 方式 之 一 包括 
引用 ConfigMap 对 象 中 的 数据 ， 这 一 点 通过 在 env 字 段 中 为 valueFrom 内 
嵌 configMapKeyRef 对 象 即 可 实现 ， 其 使 用 格式 如 下 : 


ValueFrom : 
configMapKeyRef: 
key: 
name: 
optional: 


其 中 ， 字 段 name 的 值 为 要 引用 的 ConfigMap 对 象 的 名 称 ， 字 段 key 
可 用 于 指定 要 引用 ConfigMap 对 象 中 某 键 的 键 名 ， 而 字段 optional 则 用 
于 为 当前 Pod 资 源 指明 此 引用 是 否 为 可 选 。 此 类 环境 变量 的 使 用 方式 
与 直接 定义 的 环境 变量 并 无 区 别 ， 它 们 可 被 用 于 容器 的 启动 脚本 或 直 
接 传 递 给 容器 应 用 等 。 


下 面 是 保存 于 配置 文件 configmap-env.yaml 的 资源 定义 示例 ， 它 包 
含 了 两 个 资源 ， 彼 此 之 间 使 用 “---* 相 分 隔 。 第 一 个 资源 是 名 为 
busybox-httpd-config 的 ConfigMap 对 象 ， 它 包含 了 两 个 键 值 数据 ， 第 二 
个 资源 是 名 为 configmap-env-demo 的 Pod 对 象 ， 它 通过 环境 变量 引用 了 
busybox-httpd-config 对 象 中 的 键 值 数据 ， 并 将 其 直接 传递 给 了 目 定 义 
运行 的 容器 应 用 httpd: 


apiVersion: v1 

kind: ConfigMap 

metadata: 
name: busybox-httpd-config 
namespace: default 

data: 
httpd_port: "8080" 
verbose_ level: "-VV" 


apiVersion: v1 

kind: Pod 

metadata: 
name: configmap-env-demo 
namespace: default 

spec: 


containers: 
- image: busybox 
name: busybox-httpd 
command: ["/bin/httpd"] 
args: ["-f","-p","$(HTTPD_PORT)", "$(HTTPD_LOG_ VERBOSE)"] 
env: 
- name: HTTPD_PORT 
valueFrom: 
configMapKeyRef: 
name: busybox-httpd-config 
key: httpd_port 
- Name: HTTPD_LOG_ VERBOSE 
valueFrom: 
configMapKeyRef: 
name: busybox-httpd-config 
key: verbose _ level 
optional: true 


注意 ， 在 command 或 args 字 段 中 引用 环境 变量 要 使 用 “$ 
(VAR_NAME) ”的 格式 。 待 上 面 配置 文件 中 的 资源 创建 完成 后 ， 可 
以 通过 如 下 命令 验证 Pod 资 源 监 听 的 端口 等 配置 信息 是 否 为 busybox- 
httpd-config 中 定义 的 内 容 : 


~]$ kubect1 exec configmap-env-demo ps aux 
PID USER TIME COMMAND 
1 root 0:00 /bin/httpd -f -p 8080 -vv 


全) 注意 “创建 引用 了 ConfigMap 资 源 的 pod 对 象 时 ， 被 引用 的 
资源 必须 事先 存在 ， 否 则 将 无 法 启动 相应 的 容器 ， 直 到 被 依赖 的 资源 
创建 完成 为 止 。 不 过 ， 那 些 未 引用 不 存在 的 ConfigMap 资 源 的 容器 将 
不 受 此 影响 。 另 外 ，ConfigMap 是 名 称 空间 级 别 的 资源 ， 它 必须 与 引 
用 它 的 pod 资源 在 同一 空间 中 。 


假设 存在 这 么 一 种 情形 ， 某 ConfigMap 资 源 中 存在 较 多 的 键 值 数 
据 ， 而 全 部 或 大 部 分 的 这 些 键 值 数据 都 需要 由 容 需 来 引用 。 此 时 ， 为 
容 絮 逐一 配置 相应 的 环境 变量 将 是 一 件 颇 为 劳 心 费 神 之 事 ， 而 且 极 易 
出 错 。 对 此 ，Pod 资 源 支 持 在 容器 中 使 用 envFrom 了 字段 直接 将 
Dy 键 值 一 次 性 地 完成 导入 。 它 的 使 用 格式 如 


spec: 
containers: 
- image: some-image 


envFrom: 
- prefix <string> 
configMapRef: 
name <string> 
optional <boolean> 


envFrom 字 上 段 值 是 对 象 列表 ， 可 用 于 同时 从 多 个 ConfigMap 对 和 象 导 
入 键 值 数据 。 为 了 避免 从 多 个 ConfigMap3 引 用 键 值 数据 时 产生 键 名 冲 
突 ， 可 以 在 每 个 引用 中 将 被 导入 的 键 使 用 prefix 字 段 指定 一 个 特定 的 前 
级 ， 如 “HTCFG_” 一 类 的 字符 串 ， 于 是 ，ConfigMap 对 象 中 的 httpd_port 
将 成 为 Pod 资 源 中 名 为 HTCFG_httpd_port 的 变量 。 


(加 注意。 如果 键 名 中 使 用 了 连接 线 “”， 那 么 在 转换 为 变量 名 
时 ， 连 接线 将 被 自动 替换 为 下 划 线 < ”。 


例如 ， 把 上 面 示例 中 的 Pod 资 源 转 为 如 下 形式 的 定义 (configmap- 
ee 后 ， 其 引用 ConfigMap 进 行 配 置 的 效果 并 
无 不 同 : 


apiVersion: v1 
kind: Pod 
metadata: 
name: configmap-envfrom-demo 
namespace: default 
spec: 
containers: 
- image: busybox 
name: busybox-httpd 
command: ["/bin/httpd"] 
args: ["-f","-p","$(HTCFG_httpd_port)","$(HTCFG_ verbose level)"] 
envFrom: 
- prefix: HTCFG_ 
configMapRef: 
name: busybox-httpd-config 
optional: false 


待 Pod 资 源 创 建 完 成 后 ， 可 通过 查看 其 环境 变量 验证 其 导入 的 结 


~]$ kubect1 exec configmap-envfrom-demo printenv 
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin 
HOSTNAME=configmap-envfrom-demo 

HTCFG_httpd_port=8080 

HTCFG_verbose_level=-vv 


值得 提醒 的 是 ， 从 ConfigMap 对 象 导入 资源 时 ，prefix 为 可 选 字 
段 ， 省 略 时 ， 所 有 变量 名 同 ConfigMap 中 的 键 名 。 如 果 不 存在 键 名 冲 
突 的 可 能 性 ， 例 如 从 单个 ConfigMap 对 象 导 入 变量 或 在 ConfigMap 对 象 
中 定义 键 名 时 已 然 添 加 了 特定 的 前 级 ， 那 么 省 略 前 级 的 定义 既 不 会 导 
致 键 名 冲突 ， 又 能 保持 变量 的 简洁 。 


8.4.3 ”ConfigMap 存 储 卷 


若 ConfigMap 对 象 中 的 键 值 来 源 于 较 长 的 文件 内 容 ， 那 么 使 用 环境 
变量 将 其 导入 会 使 得 变量 值 占据 过 多 的 内 存 空间 而 且 不 易 处 理 。 此 类 
数据 通常 用 于 为 容 絮 应 用 提供 配置 文件 ， 因 此 将 其 内 容 直 接 作 为 文件 
进行 引用 方 为 较 好 的 选择 。 其 实现 方式 是 ， 在 定义 Pod 资 源 时 ， 将 此 类 
ConfigMap 对 象 配 置 为 ConfigMap 类 型 的 存储 卷 ， 而 后 由 容 右 将 其 挂 载 
至 特定 的 挂 载 点 后 直接 进行 访问 。 


1. 挂 载 整个 存储 卷 


关联 为 Pod 资 源 的 存储 卷 时 ，ConfigMap 对 象 中 的 每 个 键 都 对 应 地 
表现 为 一 个 文件 ， 键 名 转 为 文件 名 ， 而 键 值 则 为 相应 文件 的 内 容 ， 即 
便 是 通过 直接 值 创建 的 键 值 数据 ， 也 一 样 表现 为 文件 视图 。 挂 载 于 容 
希 上 之 后 ， 由 键 值 数 据 表现 出 的 文件 位 于 挂 载 护 目录 中 ， 容 事 中 的 进 
程 可 直接 读 取 这 些 文件 的 内 容 。 


配置 Pod 资 源 时 ， 基 于 存储 卷 的 方式 引用 ConfigMap 对 象 的 方法 非 
常 简单 ， 仅 需要 指明 存储 卷 名 称 及 要 引用 的 ConfigMap 对 象 名 称 即 可 。 
下 面 是 于 配置 文件 configmap-volume-pod.yaml 中 定义 的 Pod 资 源 ， 它 引 
用 了 8.4.1 节 下 第 3 小 节 中 创建 的 ConfigMap 对 象 nginx-config-files， 容 器 
nginx-server 将 其 挂 载 至 应 用 程序 Nginx 加 载 配 置 文 件 模块 的 目 
录 /etc/nginx/conf.d 中 ， 具 体 如 下 : 


apiVersion: v1 
kind: Pod 
metadata: 
name: configmap-volume-demo 
namespace: default 
spec: 
containers: 
- image: nginx:alpine 

name: nginx-server 

volumeMounts: 

- name: ngxconfi 
mountPath: /etc/nginx/conf.d/ 
readonly: true 

volumes: 
- name: ngxconfig 

configMap: 
name: nginx-config-files 


此 Pod 资 源 引用 的 nginx-config-files 中 包含 三 个 配置 文件 ， 其 中 
myserver.conf 定 义 了 一 个 虚拟 主机 www.ilinux.io ， 并 通过 include 指 令 包 
含 /etcnginx/conf.d/ 目 孙 下 以 “myserver-” 为 前 丝 爱 且 以 ， cfg 为 后 绥 的 所 有 配 
置 文件 ， 例 如 在 nginx-config-files 中 包含 的 myserver-status.cfg 和 
myserver-gzip.cfg。 上 有 具体 的 配置 内 容 请 参考 8.4.1 玉 下 第 3 小 和 中 命令 的 输 
出 。 ConfigMap 存 储 卷 中 的 文件 如 图 8- 2 所 示 。 


nginx-config-files 


myserver.conf myserver-gzip.cfg 


myserver-status.cfe 


图 8-2 ”ConfigMap 存 储 卷 中 的 文件 


创建 此 Pod 资 源 后 于 Kubernetes 集 群 中 的 菜 太 点 直接 向 Pod IP 的 8080 
端 发 起 访问 请 求 ， 即 可 验证 由 nginx-config-files 资 源 提供 的 配置 信息 
否 生 效 ， 例 如 ， 通 过 /nginx-status 访 问 其 内 建 的 stub status: 


~]$ POD_IP=$(kubectl1 get pods configmap-volume-demo -0 go-template={{.status. 
podIP}}) 
~]$ curl http://${POD_IP}:8080/nginx-status 
Active connections: 1 
server accepts handled requests 
333 
Reading: 0 Writing: 1 Waiting: 0 


当然 ， 我 们 也 可 以 直接 于 Pod 资 源 的 相应 容 侨 上 执行 命令 来 确认 文 
件 是 否 存 在 于 挂 载 点 目 台 中 : 


~]$ kubect] exec configmap-volume-demo ls /etc/nginx/conf.d/ 
myserver-gzip.cfg 

myserver-status.cfg 

myserver.conf 


进一步 地 ， 还 可 以 于 容 侣 中 运行 Nginx 的 配置 测试 及 打印 命令 ， 确 
认 由 ConfigMap 资 源 提供 的 配置 信息 已 然 生效 : 


~]$ kubect] exec configmap-volume-demo -- nginx -T 
# configuration file /etc/nginx/conf.d/myserver.conf: 
server { 

listen 8080; 

Server_name www.ilinux.io; 


include /etc/nginx/conf.d/myserver-*,.cfg; 


location / { 
root /usr/share/nginx/html; 
} 


} 


# configuration file /etc/nginx/conf.d/myserver-gzip.cfg: 

gzip on; 

gzip_comp_level 5; 

gzip_proxied expired no-cache no-store private auth; 
gzip_types text/plain text/css application/xml text/javascript; 


# configuration file /etc/nginx/conf.d/myserver-status.cfg: 
location /nginx-status 区 

stub_status on; 

access_log off; 


} 


由 上 面 两 个 命令 的 结 采 可 见 ，nginx-config-files 中 的 三 个 文件 都 被 
添加 到 了 容器 中 ， 并 且 实 现 了 由 容器 应 用 Nginx 加 载 并 生效 。 


2. 挂 载 存储 关中 的 部 分 键 值 


有 时 候 ， 用 户 很 可 能 不 期 望 在 容器 中 挂 载 某 ConfigMap 存 储 卷 后 于 
挂 载 点 目录 导出 所 有 的 文件 ， 这 在 通过 一 个 ConfigMap 对 象 为 单个 Pod 
资源 中 的 多 个 容器 分 别提 供 配 置 时 尤其 常见 。 例 如 前 面 的 示例 中 ， 用 
户 可 能 只 期 望 在 容器 中 挂 载 ConfigMap 存 储 卷 后 只 “导出 ”其 中 的 
myserver.conf 和 myserver-gzip.cfg， 只 提供 页 面 传输 压缩 功能 ， 而 不 输 
出 nginx stub status 信 息 ， 此 时 将 其 volumes 配 置 段 改 为 如 下 所 示 的 内 容 
即 可 。 为 了 以 示 区 别 并 在 后 文中 便于 引用 及 说 明 问 题 ， 这 里 将 其 保存 
于 单独 的 配置 文件 configmap-volume-demo-2.yaml 中 ， 并 将 Pod 资 源 命名 


为 configmap-volume-demo-2: 


apiVersion: v1 
kind: Pod 
metadata: 


name: configmap-volume-demo-2 
namespace: default 
spec: 
containers: 
- image: nginx:alpine 
name: web-server 
volumeMounts: 
- name: ngxconfig 
mountPath: /etc/nginx/conf.d/ 
readonly: true 
volumes: 
- name: ngxconfig 
configMap: 
name: nginx-config-files 
items: 
- key: myserver.conf 
path: myserver.conf 
mode: 0644 
- key: myserver-gzip.cfg 
path: myserver-compression.cfg 


configMap 存 储 卷 的 items 字 段 的 值 是 一 个 对 象 列表 ， 可 崩 套 使 用 的 
字段 有 三 个 ， 具 体 如 下 。 


key<string> : 要 引用 的 键 名 称 ， 必 选 字段 。 


:path<string> : 对 应 的 键 于 挂 载 点 目录 中 生成 的 文件 的 相对 路 径 ， 
可 以 不 同 于 键 名 称 ， 必 选 字 段 。 


mode<integer>: 文件 的 权限 模型 ， 可 用 范围 为 0 到 0777。 


上 面 的 配置 示例 中 ，myserver-gzip.cfg 映 射 成 了 myserver- 
compression.cfg 文 件 ， 而 myserver.conf 则 保持 了 与 键 名 同名 ， 并 明确 指 
定 使 用 0644 的 权限 ， 从 而 达成 了 仪 装载 部 分 文件 至 容 絮 之 目的 。 


3. 独 立 挂 载 存储 卷 中 的 键 值 


前 述 方 式 中 ， 无 论 是 装载 所 有 文件 还 是 部 分 文件 ， 挂 载 点 目 孙 下 
原 有 的 文件 都 会 家 隐藏。 对 于 期 望 将 ConfigMap 对 象 提供 的 配置 文件 补 
充 于 挂 载 点 目录 下 的 需求 来 说 ， 这 种 方式 显然 难以 如 愿 。 例 
如 ，/etc/nginx/conf.d 目 录 中 原本 就 存在 一 些 文件 (如 default.conf) ， 用 
户 期 望 将 nginx-config-files 中 的 全 部 或 部 分 文件 装载 进 此 目录 中 而 不 影 
啊 其 原 有 的 文件 。 


事实 上 ， 此 种 需求 可 以 通过 此 前 第 7 章 中 曾经 于 容器 的 
volumeMounts 字 段 中 使 用 的 subPath 字 段 来 解决 ， 它 可 以 文 持 用 户 从 存 


储 卷 挂 载 单 个 文件 或 单个 目录 而 非 整 个 存储 卷 。 例 如 ， 下 面 的 示例 就 
于 /etc/nginx/conf.d 目 录 中 单独 挂 载 了 两 个 文件 ， 而 你 留 于 了 目录 下 原 有 
的 文件 。 为 了 以 示 区 别 并 在 后 文中 便于 引用 及 说 明 问 题 ， 这 里 将 其 保 
存 于 单独 的 配置 文件 configmap-volume-demo-3.yaml 中 ， 并 将 Pod 资 源 命 


名 为 configmap-volume-demo-3: 


apiVersion: v1 
kind: Pod 
metadata: 
name: configmap-volume-demo-3 
namespace: default 
spec: 
containers: 
- image: nginx:alpine 
name: web-server 
volumeMounts: 
- name: ngxconfig 
mountPath: /etc/nginx/conf.d/myserver.conf 
SubPath: myserver.conf 
readonly: true 
- name: ngxconfig 
mountPath: /etc/nginx/conf.d/myserver-status.cfg 
SubPath: myserver-status.cfg 
readonly: true 
volumes: 
- name: ngxconfig 
configMap: 
name: nginx-config-files 


基于 上 述 配 置 创建 了 Pod 资 源 之 后 ， 即 可 通过 命令 验 
证 /etc/nginx/conf.d 目 录 中 的 原 有 文件 确实 能 够 得 以 保留 ， 如 下 面 的 命令 
及 其 结果 所 示 : 


~]$ kubect] exec configmap-volume-demo-3 Js /etc/nginx/conf.d 
default.conf 

myserver-gzip.cfg 

myserver.conf 


8.4.4 容 敌 应 用 重 载 新 配置 


相 较 于 环境 变量 来 说 ， 使 用 ConfigMap 资 源 为 容器 应 用 提供 配置 
的 优势 之 一 在 于 其 支持 容 右 应 用 动态 更 新 其 配置 .用户 直接 更 新 
ConfigMap 对 象 ， 而 后 由 容器 应 用 重 载 其 配置 文件 即 可 。 


细心 的 读者 或 许 已 经 发 现 ， 挂 载 ConfigMap 存 储 卷 的 挂 载 点 目录 
中 的 文件 都 是 符号 链接 ， 它 们 指向 了 当前 目录 中 的 “..data”， 
而 “..data” 也 是 符号 链接 ， 它 指向 了 名 字形 
如 “..2018_03_17_14 41 41.256460087” 的 目录 ， 这 个 目录 才 是 存储 卷 
的 真正 挂 载 点 。 例 如 ， 查 看 8.4.3 世 下 第 1 小 和 中 创建 的 Pod 资 源 容 妖 中 
的 挂 载 点 中 的 文件 列表 ， 它 将 显示 出 类 似 如 下 结果 : 


~]$ kubect1 exec -it configmap-volume-demo -- 1s -lA /etc/nginx/conf.d 

total 0 

drwxr-xr-x 2 root root 79 Mar 17 14:41 ..2018_03_17_14 41 41.256460087 

Jrwxrwxrwx 1 root root 31 Mar 17 14:41 ..data -> 

, .2018_03_17_14 41 41.256460087 

lrwxrwxrwx 1 root root 24 Mar 17 10:19 myserver-gzip.cfg -> ..data/myserver- 
gzip.cfg 

lrwxrwxrwx 1 root root 26 Mar 17 10:19 myserver-status.cfg -> 

, .data/myserver- 
status.cfg 

lrwxrwxrwx 1 root root 20 Mar 17 10:19 myserver.conf -> ..data/myserver.conf 


这 样 两 级 符号 链接 设 定 的 好 处 在 于 ， 在 引用 的 ConfigMap 对 和 象 中 
的 数据 发 生 改 变 时 ， 它 将 被 重新 挂 载 至 一 个 新 的 临时 目 示 下 ， 而 
后 “..data” 将 指向 此 新 的 挂 载 点 ， 便 达到 了 同时 更 新 存储 卷 上 所 有 文件 
数据 之 目的 。 例 如 ， 使 用 kubectl edit 命 令 直 接 在 ConfigMap 对 象 nginx- 
config-files 中 的 myserver-status.cfg 配 置 段 中 增加 “allow 
127.0.0.0/8; ”和 “deny all; ”两 行 ， 而 后 再 次 查看 configmap-volume- 
demo 中 的 容器 的 挂 载 点 目 孙 中 的 文件 列表 ， 结 果 是 其 挂 载 点 已 经 指向 
了 新 的 位 置 ， 例 如 下 面 的 命令 及 其 结果 所 示 : 


~]$ kubect1 exec -it configmap-volume-demo -- 1s -lA /etc/nginx/conf.d 

total 0 

rwxr -xr-x 2 root root 79 Mar 17 15:17 ..2018_03_17_15_17_11.170451948 
lrwxrwxrwx 1 root root 31 Mar 17 15:17 ..data -> 

, .2018_03_17_15_17_11.170451948 


lrwxrwxrwx 1 root root 24 Mar 17 10:19 myserver-gzip.cfg -> ..data/myserver- 
gzip.cfg 


lrwxrwxrwx 1 root root 26 Mar 17 10:19 myserver-status.cfg -> 
, .data/myserver- 
status.cfg 
lrwxrwxrwx 1 root root 20 Mar 17 10:19 myserver.conf -> ..data/myserver.conf 


此 时 ， 大 要 使 容器 中 应 用 程序 的 新 配置 生效 ， 则 需要 于 Pod 资 源 
的 相应 容器 上 执行 配置 重 载 操作 。 例 如 ，Nginx 可 通过 其 “nginx-s 
reload” 命 令 完成 配置 文件 重 载 ， 如 下 面 的 命令 所 示 : 


~]$ kubectl1 exec configmap-volume-demo -- nginx -s reload 
2018/08/17 15:18:19 [notice] 222#222: signal process started 


此 时 ， 如 果 于 此 容器 之 外 的 位 置 访问 mginx-status 页 面 的 请 求 是 被 
拒绝 的 ， 则 表明 痢 配 置 已 然 生 效 ， 如 下 面 的 命令 及 其 结 采 所 示 : 


~]$ curl http://${POD_IP}:8080/nginx-status 
<html> 

<head><title>403 Forbidden</title></head> 
<body bgcolor="white"> 

<center><h1>403 Forbidden</h1i></center> 
<hr><center>nginx/14.13.9</center> 

</body> 

</html> 


然而 ， 需 要 注意 的 是 ， 对 于 不 文 持 配 置 文件 重 载 操 作 的 容 右 应 用 
来 说 ， 只 有 那些 在 ConfigMap 对 和 象 更 新 后 创建 的 Pod 资 源 中 的 容 紫 会 应 
用 到 新 配置 ， 此 时 如 果 不 重启 旧 有 的 容 右 ， 则 会 导致 配置 不 一 致 的 问 
题 。 即 使 对 于 文 持 重 载 操 作 的 应 用 来 说 ， 由 于 痢 的 配置 信息 并 非 同步 
推送 进 所 有 容 絮 中 ， 而 且 各 容器 的 重 载 操作 也 未 必 能 同时 进行 ， 因 此 
在 更 新 时 ， 短 时 间 内 仍然 会 存在 配置 不 一 致 的 现象 。 


另外， 使 用 8.4.3 下 第 3 小 市 中 的 方式 独立 挂 载 存 储 卷 中 的 文件 的 容 
硬 ， 其 挂 载 配 置 文 件 的 方式 并 非 是 以 两 级 链接 的 方式 进行 的 ， 因 此 存 
储 着 无 法 确保 所 有 挂 载 的 文件 可 以 被 同时 更 新 至 容 磺 中， 因此 为 了 确 
保 配 置信 息 的 一 致 性 ， 目 前 这 种 类 型 的 挂 载 不 文 持 文 件 更 狐 操 作 。 读 
者 可 对 此 目 行 进行 验证 。 


8.4.5 “使 用 ConfigMap 资 源 的 注意 事项 


在 Pod 资 源 中 调用 ConfigMap 对 象 时 需要 注意 以 下 几 个 问题 。 


-以 存储 卷 方式 引用 的 ConfigMap 必 须 先 于 Pod 存 在 ， 除 非 在 Pod 中 
将 它们 全 部 标记 为 <optional"， 否 则 将 会 导致 pod 无 法 正常 启动 的 错 
识 ， 同样 ， 即 使 在 ConfigMap， 在 引用 的 键 不 存在 时 ， 也 会 导致 一 

9 错误 。 


. 当 以 环境 变量 方式 注入 的 ConfigMap 中 的 键 不 存在 时 会 被 名 略 ， 
Pod 可 以 正常 启动 ， 但 错误 引用 的 信息 会 以 “InvalidVariableNames” 事 件 
记录 于 日 志 中 。 

.ConfigMap 是 名 称 空 间 级 的 资源 ， 因 此 ， 引 用 它 的 Pod 必 须 处 于 同 
一 名 称 空间 中 。 


.kubelet 不 文 持 引用 Kubernetes API Server 上 不 存 的 ConfigMap， 这 
包括 那些 通过 kubelet 的 “--manifestrurl” 或 “--config” 选 项 ， 以 及 kubelet 
REST API 创 建 的 Pod 。 


8.5” Secret 资源 


Secret 资 源 的 功能 类 似 于 ConfigMap ， 但 它 专用 于 存放 敏感 数据 ， 
例如 密码 、 数 字 证 书 、 私 钥 、 令 牌 和 SSH key 等 。 


8.5.1 _ Secret 概述 


Secret 对 象 存 储 数据 的 方式 及 使 用 方 民 关 似 于 ConfigMap 对 象 ， 以 
键 值 方式 存储 数据 ， 在 Pod 资 源 中 通过 环境 变量 或 存储 卷 进行 数据 访 
问 。 不 同 的 是 ，Secret 对 象 仅 会 被 分 发 至 调用 了 此 对 象 的 Pod 资 源 所 在 
的 工作 节点 ， 且 只 能 由 节点 将 其 存储 于 内 存 中 。 男 外 ，Secret 对 象 的 数 
据 的 存储 及 打印 格式 为 Base64 编 码 的 字符 串 ， 因 此 用 户 在 创建 Secret 对 
象 时 也 要 提供 此 种 编码 格式 的 数据 。 不 过 ， 在 容器 中 以 环境 变量 或 存 
储 卷 的 方式 访问 时 ， 它 们 会 被 自 动 解码 为 明文 格式 。 


需要 注意 的 是 ， 在 Master 节 点 上 ，Secret 对 象 以 非 加 密 的 格式 存储 
于 etcd 中 ， 因 此 管理 员 必 须 加 以 精心 管控 以 确保 敏感 数据 的 机 密 性 ， 必 
须 确保 etcd 集 群 节点 间 以 及 与 API Server 的 安全 通信 ，etcd 服 务 的 访问 授 
权 ， 还 包括 用 户 访问 API Server 时 的 授权 ， 因 为 拥有 创建 Pod 资 源 的 用 
户 都 可 以 使 用 Secret 资 源 并 能 够 通过 Pod 中 的 容器 访问 其 数据 。 


Secret 对 象 主要 有 两 种 用 途 ， 一 是 作为 存储 卷 注 入 到 Pod 上 由 容器 
应 用 程序 所 使 用 ， 二 是 用 于 kubelet 为 Pod 里 的 容器 拉 取 镜像 时 各 私有 仓 
库 提 供认 证 信息 。 不 过 ， 后 面 使 用 ServiceAccount 资 源 自 建 的 Secret 对 和 象 
0 式 。 通 过 ConfigMap 和 Secret 配 置 容器 的 方式 如 

8-3 所 不 。 


Secrets "Config map" 


+aPvKE0i A apiVersion:vl1 
1385guD+qPvKOJLtz1 Kind:ConfieMi 
uCScMk8qqKXQkSg metadata: 
ylNy2E04tlgRTyblRn name:special-config 


4u7qiUDyPQPxw3LhT RA ona Desieals 
aHzYJsn/pBcw34m9K SR oo \ SN SPECIAL LEVEL:5 
nHykNkRMCn8GCJH SS 4 NODE ENV:staging 
vcajB hy 


Secret 资 源 主 要 由 四 种 类 型 组 成 ， 具 体 如 下 


.Opaque: 目 定义 数据 内 容 ; base64 编 码 ， 用 来 存储 密码 、 密 钥 、 
信息 、 证 书 等 数据 ， 类 型 标识 从 为 generic 。 


kubernetes.io/service-account-token: Service Account 的 认证 信息 
可 在 创建 i 


可 在 创建 Service Accout 时 由 Kubernetes 自 动 创 
kubernetes.io/dockerconfigjson: 用 来 存储 Docker 镜 像 仓库 的 认证 信 
， 类 型 标识 为 docker-registry 。 
:kubernetes.io/tls: 用 于 为 SSL 通 信 模 式 存储 证 书 和 私 钥 文件 ， 
式 创建 时 类 型 标识 为 ts。 


萌 念 
FS 


《注音 base64 编 码 并 非 加 密 机 制 ， 其 编码 的 数据 可 使 
用 “base64--decode” 一 类 的 命令 进行 解码 。 


8.5.2 ”创建 Secret 资 源 


手动 创建 Secret 对 象 的 方式 有 两 种 : 通过 kubectl create 命 令 和 使 用 
Secret 配 置 文件 。 


1. 命 令 式 创建 


不 少 场景 中 ，Pod 中 的 应 用 需要 通过 用 户 名 和 密码 访问 其 他 服 
务 ， 例 如 访问 数据 库 系统 等 。 创 建 此 类 的 Secret 对 象 ， 可 以 使 
用 “kubectl create secret generic<SECRET_NAME>--from- 
literal=key=value” 命 令 直 接 进 行 创 建 ， 不 过 为 用 户 认 证 之 需 进 行 创建 
时 ， 其 使 用 的 键 名 通常 是 username 和 password。 例 如 下 面 的 命令 ， 
以 “root/ikubernetes” 分 别 为 用 户 名 和 密码 创建 了 一 个 名 为 mysql-auth 的 
Secret 对 和 象 : 


~]$ kubectl1 create secret generic mysql-auth --from-literal=username=root \ 
--from-literal=password=ikubernetes 


而 后 即 可 查看 新 建 资 源 的 属性 信息 ， 由 下 面 的 命令 及 其 输出 结果 
可 以 看 出 ， 以 generic 标 识 符 创建 的 Secret 对 象 是 为 Opaque 类 型 ， 其 键 
值 数 据 会 以 Base64 的 编码 格式 进行 保存 和 打印 : 


~]$ kubect1 get secrets mysql-auth -0 yaml 
apiVersion: v1 
data: 
password: aWwt1iYmVybmVOZXM= 
username: cm9vdA== 
kind: Secret 
metadata: 


type: Opaque 


不 过 ，Kubernetes 系 统 的 Secret 对 象 的 Base64 编 码 的 数据 并 非 加 密 
格式 ， 许 多 相关 的 工具 程序 均 可 轻松 完成 解码 ， 如 下 面 所 示 的 Base64 


会- 公 
命令 : 


~]$ echo awtiYmVybmVOZXM= | base64 -d 
ikubernetes 


对 于 本 吴 业 已 存储 于 文件 中 的 数据 ， 也 可 以 在 创建 generic 格 式 
Secret 对 象 时 使 用 “--from-file” 远 项 从 文件 中 直接 进行 加 载 ， 例 如 创建 
用 于 SSH 认 证 的 Secret 对 象 时 ， 如 采 尚 且 没 有 认证 信息 文件 ， 则 需要 首 
先 使 用 命令 生成 一 对 认证 文件 : 


~]$ ssh-keygen -t rsa -P '' -f ${HOME}/.ssh/id_rsa 


而 后 使 用 "kubectl create secret generic<SECRET_NAME>--from- 
file[=KEY1]=/PATH/TO/FILE” 命 令 加 载 文 件 内 容 并 生成 为 Secret 对 象 : 


~]$ kubectl1 create secret generic ssh-key-secret --from-file=ssh- 
privatekey=${HOME}/. 
ssh/id_rsa --from-file=ssh-publickey=${HOME}/.ssh/id_rsa.pub 


另外 ， 若 要 基于 私 钥 和 数字 证 书 文 件 创建 用 于 SSL/TLS 通 信 的 
Secret 对 象 ， 则 需要 使 用 “kubectl] create secret tls<SECRET_NAME>-- 
cert=--key=” 命 令 来 进行 ， 注 意 其 类 型 标识 符 为 TLS。 例 如 ， 假 设 需要 
为 Nginx 测 试 创 建 SSL 虚 拟 主机 ， 用 户 首先 使 用 了 类 似 如 下 的 命令 生成 
了 私 铀 和 目 签证 书 : 


~]$ (umask 077; openss1l1 genrsa -out nginx.key 2048) 
~]$ openssl req -new -x509 -key nginx.key -out nginx.crt \ 
-Subj /C=CN/ST=Beijing/L=Beijing/0=DevOps/CN=www.ilinux.io 


而 后 即 可 使 用 如 下 命令 将 这 两 个 文件 创建 为 Secret 对 象 。 需 要 注意 
的 是 ， 无 论 用 户 提供 的 证 书 和 私 角 文件 使 用 的 是 什么 名 称 ， 它 们 一 律 
会 被 转换 为 分 别 以 tls.key ( 私 钥 ) 和 tls.crt (证 书 ) 为 其 键 名 : 


~]$ kubectl1 create secret tls nginx-ssl --key=./nginx.key --cert=./nginx,.crt 
Secret "nginx-ssl" created 


注意 其 类 型 应 该 为 “kubernetes.io/tls”， 例 如 下 面 命 令 结果 中 的 显 


和 小 : 


~]$ kubect1 get secrets nginx-ssl 
NAME TYPE DATA AGE 
nginx-ssl kubernetes.io/tls 2 37S 


由 上 述 操 作 过 程 可 见 ， 命 令 式 创建 Secret 对 象 与 ConfigMap 对 象 的 
方式 几乎 没有 明显 区 别 。 


2. 清 单 式 创 建 


Secret 资 源 是 标准 的 Kubernetes API 对 象 ， 除 了 标准 的 apiVersion 、 
kind 和 metadata 字 段 ， 它 可 用 的 其 他 字段 具体 如 下 。 


.data<map[string]string>: “key: value” 格 式 的 数据 ， 通 常 是 敏感 信 
人 因此 需要 用 户 事 先 完 
:编码 。 


stringData<map[string]string>: 以 明文 格式 〈 非 Base64 编 码 ) 定义 
的 “key: value” 数 据 ， 无 须 用 户 事先 对 数据 进行 Base64 编 码 ， 而 是 在 创 
建 为 Secret 对 象 时 目 动 进行 编码 并 保存 于 data 字 段 中 ; stringData 字 段 中 
的 明文 不 会 被 API Server 输 出 ， 不 过 车 是 使 用 “kubectl apply” 命 令 进 行 
的 创建 ， 那 么 注解 信息 中 还 是 可 能 会 直接 输出 这 些 信 息 的 。 


十 ye 仅 是 为 了 便于 编程 方式 处 理 Secret 数 据 而 提供 的 类 
型 未 识 加 


下 面 是 保存 于 配置 文件 secret-demo.yaml 中 的 Secret 资 源 定 义 示 
例 ， 其 使 用 stringData 提 供 了 明文 格式 的 键 值 数 据 ， 从 而 免 去 了 事先 进 
行 手动 编码 的 所 烦 : 


apiVersion: v1 
kind: Secret 
metadata: 
name: secret-demo 
stringData: 
username: redis 
password: redisp@ss 
type: Opaque 


Secret 对 象 也 是 Kubermmetes 系 统 的 “一 等 公民 ”， 因 此 ， 使 用 标准 资 
源 创建 命令 即 可 完成 其 创建 。 相 比较 来 说 ， 基 于 清单 文件 将 保存 于 文 


件 中 的 敏感 信息 创建 Secret 对 象 时 ， 用 户 首先 需 要 将 敏感 信息 读 出 ， 转 
为 Base64 编 码 格式 ， 而 后 再 将 其 创建 为 清单 文件 ， 过 程 烦 开 ， 反 不 如 
命令 式 创建 来 得 便捷 。 不 过 ， 如 采 存 在 多 次 创建 或 重 构 之 需 ， 那 么 将 
其 保存 为 配置 清单 也 十 情 势 所 需 。 


8.5.3” Secret 存储 卷 


类 似 于 Pod 消 费 ConfigMap 对 象 的 方式 ，Secret 对 象 可 以 注入 为 环 
境 变量 ， 也 可 以 存储 为 卷 形式 挂 载 使 用 。 不 过 ， 容 锅 应 用 通常 会 在 发 
生 错 误 时 将 所 有 环境 变量 保存 于 日 志 信 息 中 ， 甚 至 有 些 应 用 在 局 动 时 
即 会 将 运行 环境 打印 到 日 志 中 ; 另外， 容器 应 用 调用 第 三 方程 序 为 子 
进程 时 ， 这 些 子 进程 能 够 继承 并 使 用 父 进程 的 所 有 环境 变量 。 有 鉴于 
此 ， 使 用 环境 变量 引用 Secret 对 象 中 的 敏感 信息 实在 算 不 上 明智 之 举 。 


在 Pod 中 使 用 Secret 存 储 卷 的 方式 ， 除 了 其 类 型 及 引用 标识 要 替换 
为 Secret 及 secretName 之 外 ， 几 乎 完全 类 似 于 ConfigMap 存 储 卷 ， 包 括 
文 持 使 用 挂 载 整 个 存储 卷 、 只 挂 载 存 储 卷 中 的 指定 键 值 以 及 独立 挂 载 
存储 卷 中 的 键 等 使 用 方式 。 


下 面 是 定义 在 配置 文件 secret-volume-pod.yaml 中 的 Secret 资 源 使 用 
示例 ， 它 将 nginx-ssl 关 联 为 Pod 资 源 的 名 为 nginxcert 的 Secret 存 储 卷 ， 而 
后 由 容器 web-servrer 挂 载 至 /etc/nginx/ssl 目 录 下 : 


apiVersion: v1 
kind: Pod 
metadata: 

name: secret-volume-demo 

namespace: default 

spec: 

containers: 

- image: nginx:alpine 
name: web-server 
volumeMounts: 

- name: nginxcert 
mountPath: /etc/nginx/ssl/ 
readonly: true 

volumes: 

- name: nginxcert 
secret: 

secretName: nginx-ssl 


将 上 面 资源 清单 文件 中 定义 的 资源 创建 于 Kubernetes 系 统 上 ， 而 
后 再 查看 容 絮 挂 载 点 目录 中 的 文件 ， 以 确认 其 挂 载 是 否 成 功 完 成 。 下 
面 命令 的 结果 显示 ， 私 钥 文件 ts.key 和 证 书 文件 ts.crt 已 经 成 功 保存 于 
挂 载 点 路 径 之 下 : 


~]$ kubect1 exec secret-volume-demo ls /etc/nginx/ssl/ 
tls.crt 
tls.key 


此 时 ， 通 过 ConfigMap 对 象 为 容器 应 用 Nginx 提 供 HTTPS 虚 拟 主机 
配置 ， 它 只 要 使 用 由 Secret 对 象 生成 的 私 铀 和 证 书 文件 ， 即 可 定义 出 容 
器 化 运行 的 Nginx 服 务 。 


8.5.4 _ imagePullSecret 资 源 对 象 


imagePullSecret 资 源 可 用 于 辅助 kubelet 从 需要 认证 的 私有 镜像 仓库 
获取 镜像 ， 它 通过 将 Secret 提 供 的 密码 传递 给 kubelet 从 而 在 拉 取 镜像 前 
完成 必要 的 认证 过 程 。 


使 用 imagePullSecret 的 方式 有 两 种 : 一 是 创建 docker-registry 类 型 
的 Secret 对 象 ， 并 在 定义 Pod 资 源 时 明确 通过 “imagePullSecrets” 字 段 给 
出 ， 男 一 个 是 创建 docker-registry 类 型 的 Secret 对 象 ， 将 其 添加 到 某 特 
定 的 ServiceAccount 对 象 中 ， 那 些 使 用 该 ServiceAccount 资 源 创建 的 Pod 
对 象 ， 以 及 默认 使 用 该 ServiceAccount 的 Pod 对 象 都 将 会 直接 使 用 
imagePullSecrets 中 的 认证 信息 。 由 于 尚未 介绍 到 ServiceAccount 资 源 ， 
此 这 里 先 介 绍 第 一 种 方式 的 用 法 。 


创建 docker-registry 类 型 的 Secret 对 象 时 ， 要 使 用 “kubectl create 
secret docker-registry<SECRET_ NAME>--docker-user=<USERNAME>-- 
docker-password=<PASSWORD>--docker-email= 
<DOCKER_USER_EMAIL>” 的 命令 格式 ， 其 中 的 用 户 名 、 密 码 及 邮件 
信息 是 在 使 用 docker login 命 令 登 录 时 使 用 的 认证 人 信息。 例如， 下面 的 
命令 创建 了 名 为 local-registry 的 image pull secret 对 象 


~]$ kubect1l create secret docker-registry local-registry --docker-username=Ops \ 
--docker-password=opspass --docker-email=ops@ilinux.io 


此 类 Secret 对 象 打印 的 类 型 信息 
为 “kubernetes.io/dockerconfigjson”， 如 下 面 的 命令 结果 所 示 : 


~]$ kubect1 get secrets local-registry 
NAME TYPE DATA AGE 
local-registry kubernetes.io/dockerconfigjson 1 7S 


而 后 ， 使 用 相应 的 私有 registry 中 镜像 的 Pod 资 源 的 定义 ， 即 可 通 
0 此 Secret 对 象 ， 使 用 示例 如 下 面 的 配置 清单 
和 个 : 


apiVersion: v1 

kind: Pod 

metadata: 
name: secret-imagepull-demo 
namespace: default 

spec: 
imagePullSecrets: 
- name: local-registry 
containers: 
- image: registry.ilinux.io/dev/myimage 

name: myapp 


上 面 的 配置 清单 仅 是 一 个 示例 ， 付 诸 运 行 时 ， 需 要 由 读者 将 其 
et 的 内 容 及 清单 资源 的 镜像 等 信息 的 定义 修改 为 实际 可 用 的 信 


人 


试想 ， 正 在 运行 的 多 数 容器 的 镜像 均 来 日 于 私有 仓库 时 ， 为 每 个 
Pod 资 源 显 式 定 义 imagePullSecrets 实 在 不 是 一 个 好 主意 。 好 在 还 有 基于 
ServiceAccount 的 image pull secret 可 用 。 


8.6 本章 小 结 

本 音 的 核心 目标 在 于 为 读者 说 明 配置 容器 应 用 的 常用 方式 ， 这 在 
将 同一 Pod 资 源 分 别 以 不 同 的 配置 运行 于 不 同 的 环境 中 时 特别 有 用 。 
本 章 主要 描述 了 如 下 几 种 配置 容器 化 应 用 的 方式 。 

. 自 定义 命令 行 选项 ， 为 容器 化 应 用 传递 特定 参数 。 

.通过 环境 变量 向 容器 注入 自 定义 数据 。 


Ee 0 以 环境 变量 或 存储 卷 的 形式 向 容 妖 提供 配 


-借助 Secret 对 象 ， 以 存储 卷 的 形式 同 容器 应 用 提供 敏感 信息 。 


第 9 章 ”StatefulSet 探 制 器 


应 用 程序 存在 “有 状态 ”和 “无 状态 ”两 种 类 别 ， 因 为 无 状态 类 应 用 
的 Pod 资 源 可 按 需 增加 、 减 少 或 重 构 ， 而 不 会 对 由 其 提供 的 服务 产生 
除了 并 发 响应 能 力 之 外 的 其 他 严重 影响 。Pod 资 源 的 常用 控制 器 中 ， 
Deployment、ReplicaSet 和 DaemonSet 等 常用 于 管理 无 状态 应 用 。 但 实 
际 情况 是 ， 应 用 本 身 束 是 分 布 式 的 集群 ， 各 应 用 实例 彼此 之 间 存 在 着 
天 联 关系 ， 甚 至 是 次 序 、 角 色 方 面 的 相关 性 ， 其 中 的 每 个 实例 都 有 其 
目 身 的 独特 性 而 无 法 轻易 由 其 他 实例 所 取代 。 本 章 的 主要 目标 瓯 是 描 
述 专用 于 管理 此 类 应 用 的 Pod 资 源 的 控制 右 StatefulSet 。 


9.1 StatefulSet 概 述 


ReplicaSet 探 制 恬 可 用 来 管控 无 状态 应 用 ， 例 如 提供 静态 内 容 服务 
的 web 服务器 程序 等 ， 而 对 于 有 状态 应 用 的 管控 ， 则 是 另 一 项 专用 控 
制 器 的 任务 一 StatefulSet 。 


9.1.1 Stateful 以 用 和 Stateless 心 用 


应 用 程序 与 用 户 、 设 备 、 其 他 应 用 程序 或 外 部 组 件 进行 通信 时 ， 
根据 其 是 否 需 要 记录 前 一 次 或 多 次 通信 中 的 相关 事件 信息 以 作为 下 一 
次 通信 的 分 类 标准 ， 可 以 将 那些 需要 记录 信息 的 应 用 程序 称 为 有 状态 
(stateful) 应 用 ， 而 无 须 记 录 的 则 称 为 无 状态 (stateless) 应 用 。 下 面 
我 们 先 来 了 解 下 状态 和 存储 的 关系。 


:状态 古 进程 的 时 间 属 性 。 无 状态 意味 着 一 个 进程 不 必 跟 肾 过 去 的 
交互 操作 ， 本 质 上 可 以 说 它 是 一 个 纯粹 的 功能 性 行为 。 对 应 地 ， 有 状 
态 则 意味 着 进程 存储 了 以 前 交互 过 程 的 记录 ， 并 且 可 以 基于 它 对 新 的 
请 求 进行 啊 应 。 至 于 状态 信息 被 保存 在 内 存 中 ， 或 者 持 久保 存 于 位 组 
上 ， 则 是 男 外 一 个 问题 。 


.存储 是 表述 持久 保存 数据 的 方法 ， 现 今 通 常 是 指 机 械 硬 盘 或 SSD 
设备 。 帮 进程 仅 需 操 作 内 存 中 的 数据 ， 则 表示 其 无 须 进 行 磁盘 IO 操 
0 0 0 


如 图 9-1 所 示 ， 将 状态 和 存储 这 两 个 概念 正 交 于 坐标 系 中 ， 则 可 以 
归结 出 如 下 几 种 应 用 程序 类 型 。 


stateful 


counter # 


financial 


. User 
shopping transaction 
management 
basket 
no read-only read-write 
disk LO disk VO disk TO 
geo coordinates file upload 
converter 


(> web server 


stateless 
图 9-1 状态 和 存储 的 关系 
象限 A 中 是 那些 具有 读 写 人 磁盘 需求 的 有 状态 应 用 程序 ， 如 支持 事 


务 功能 的 各 种 RDBMS 存 储 系 统 ; 另外 各 种 分 布 式 存储 系统 也 是 此 类 应 
用 程序 的 典型 ， 如 Redis Cluster、MongoDB 、ZooKeeper 和 Cassandra 
答 。 


-象限 B 中 包含 两 类 应 用 程序 : 一 类 是 那些 具有 读 写 磁盘 需求 的 无 
状态 应 用 程序 ， 如 具有 需 等 性 的 文件 上 传 类 服务 程序 ， 允 一 类 是 仅 需 
只 读 类 WO 访问 的 无 状态 应 用 程序 ， 例 如 ， 从 外 部 存储 加 载 静 态 资源 以 
响应 用 户 请 求 的 Web 服 务 程序 。 


:象限 C 中 是 无 磁盘 访问 需求 的 无 状态 应 用 程序 ， 如 地 理 坐 标 转 换 
故 应 用 


-象限 D 中 是 无 磁盘 访问 需求 的 有 状态 应 用 程序 ， 如 电子 商城 程序 
中 的 购物 车 系统 。 


不 过 ， 用 户 拥 有 放置 应 用 程序 的 部 分 自由 度 ， 例 如 ， 使 用 购物 车 
的 电子 商城 系统 中 ， 一 般 需 要 确保 购物 车 里 的 物品 在 整个 会 话 期 间 均 


保持 可 用 状态 ， 因 此 它 可 能 不 允许 使 用 纯 内 存 的 解决 万 案 。 男 外 ， 设 
计 有 状态 应 用 程序 时 需要 着 重 考虑 的 另 一 个 方面 是 数据 持久 存储 的 位 
置 ， 在 应 用 程序 所 在 的 节点 发 生 故 障 后 依然 需要 确保 数据 可 被 访问 的 
站 否则 使 用 节点 本 地 存储 郑 即 
DI o 


9.1.2 StatefulSet 控 制 器 概述 


前 面 章 广 中 曾 讲 到 ，ReplicaSet 控 制 妖 能 够 从 一 个 预 置 的 Pod 模 板 
创建 一 个 或 多 个 Pod 资 源 ， 除 了 主机 名 和 IP 地 址 等 属性 之 外 ， 这 些 Pod 
资源 并 没有 本 质 上 的 区 别 ， 就 连 它 们 的 名 称 也 是 使 用 同一 种 散 列 模式 
用， 具有 很 强 的 相似 性 。 通 常 ， 每 一 个 访问 请 求 都 会 以 与 其 他 请 求 
相隔 离 的 方式 被 这 类 应 用 所 处 理 ， 不 分 先后 也 无 须 关 心 它 们 是 否 存 在 
关联 关系 ， 哪 人 它们 先后 来 目 于 同一 个 请 求 者 。 于 是 ， 任 何 一 个 Pod 
资源 都 可 以 被 ReplicaSet 控 制 右 重 构 出 的 新 版 本 所 替代 ， 管 理 员 更 多 关 
注 的 也 是 它们 的 群体 特征 ， 而 无 须 过 于 关注 任何 一 个 个 体 。 提 供 静 态 
内 容 服务 的 Web 服 务 堪 程序 是 这 类 应 用 的 典型 代表 之 一 。 


对 应 地 ， 另 一 类 应 用 程序 在 处 理 客 户 端 请 求 时 ， 对 当前 请 求 的 处 
理 需 要 以 前 一 次 或 多 次 的 请 求 为 基础 进行 ， 痢 客户 端 发 起 的 请 求 则 会 
被 其 施加 专用 标识 ， 以 确保 其 后 续 的 请 求 可 以 被 识别 。 电 商 或 社交 等 
一 类 Web 应 用 站 点 中 的 服务 程序 通 销 属 于 此 类 应 用 。 另 外 还 包含 了 以 
更 强 关 联 关 系 处 理 请 求 的 应 用 ， 例 如 ，RDBMS 系 统 上 处 于 同一 个 事务 
中 的 多 个 请 求 不 但 彼此 之 间 存 在 关联 性 ， 而 且 还 要 以 严格 的 顺序 执 
行 。 这 类 应 用 一 般 需要 记录 请 求 连接 的 相关 信息 ， 即 “状态 ”， 有 的 甚 
至 还 需要 持久 保存 由 请 求生 成 的 数据 ， 尤 其 是 存储 服务 类 的 应 用 ， 运 
行 于 Kubemetes 系 统 上 时 需要 用 到 持久 存储 卷 。 


若 ReplicaSet 控 制 器 在 Pod 模 板 中 包含 了 某 PVC (Persistent Volume 
Claim) 的 引用 ， 则 由 它 创建 的 所 有 Pod 资 源 都 将 共享 此 存储 卷 。PVC 
后 端的 PV 访问 模型 配置 为 Read-OnlyMany 或 ReadWriteMany 有 上 时， 这些 
Pod 资 源 中 的 容器 应 用 挂 载 存 储 卷 后 也 就 有 了 相同 的 数据 集 。 不 过 ， 

大 多 数 情况 是 ， 一 个 集群 系统 的 分 布 式 应 用 中 ， 每 个 实例 都 有 可 能 需 
要 存储 使 用 不 同 的 数据 集 ， 或 者 各 自 拥 有 其 专 有 的 数据 副本 ， 例 如 ， 
分 布 式 文件 系统 GlusterFS 和 分 布 式 文档 存储 MongoDB 中 的 每 个 实例 各 
自 使 用 专 有 的 数据 集 ， 分 布 式 服务 框架 ZooKeeper 以 及 主 从 复制 集群 中 
的 Redis 的 每 个 实例 各 目 拥有 其 专用 的 数据 副本 。 由 于 ReplicaSet 控 制 
器 使 用 同一 个 模板 生成 Pod 资 源 ， 显 然 ， 它 无 法 实现 为 每 个 Pod 资 源 创 
建 专用 的 存储 卷 。 别 的 可 考虑 使 用 的 方案 中 ， 目 主 式 Pod 资 源 没有 上 自 
您 能 力 ， 而 组 织 多 个 只 负责 生成 一 个 Pod 资 源 的 ReplicaSet 探 制 器 则 有 
规模 扩展 不 便 的 尴 众 。 


进一步 来 说 ， 除 了 要 用 到 专 有 的 持久 存储 卷 之 外 ， 有 些 集群 类 的 
分 布 式 应 用 实例 在 运行 期 间 还 存在 角色 上 的 差异 ， 它 们 存在 单 癌 / 双 癌 
的 基于 IP 地 址 或 主机 名 的 引用 关系 ， 例 如 主 从 复制 集群 中 的 MySQL 从 
万 点 对 主 万 点 的 引用 。 这 类 应 用 实例 ， 每 一 个 都 应 当 作 一 个 独立 的 个 
体 对 待 。ReplicaSet 对 象 控 制 下 的 Pod 资 源 重 构 后 ， 其 名 称 和 IP 地 址 都 
存在 变动 的 可 能 性 ， 因 此 也 无 法 适 配 此 种 场景 之 需 。 而 StatefulSet (有 
状态 副本 集 ) 则 是 专门 用 来 满足 此 类 应 用 的 控制 器 类 型 ， 由 其 管控 的 
2 和 专 有 存储 卷 ， 即 便 被 重 构 后 亦 能 

可 个 父 。 


对 比 可 见 ，ReplicaSet 管 探 下 的 Pod 资 源 更 像 是 一 群 “ 家 
畜 ”(cattle) ， 它 们 无 状态 ， 每 个 个 体 均 被 无 区 别 地 对 待 ， 因 此 也 就 
可 在 任意 时 刻 被 男 一 个 具有 不 同 标识 的 同类 事物 所 取代 。 而 StatefulSet 
控制 器 治 下 的 Pod 资 源 更 像 是 多 个 “宠物 ”(pet) ， 每 一 个 实例 都 有 着 
其 特有 的 状态 ， 即 使 被 重 构 ， 也 得 与 其 前 任 拥 有 相同 的 标识 。 事 实 
上 ,在 云 原 生 应 用 的 体系 里 有 两 组 常用 的 近义词 ， 第 一 组 是 无 状态 
(stateless) 、 牲 畜 (cattle) 、 无 名 (nameless) 和 可 丢弃 
(disposable) ， 它 们 都 可 用 于 表 壕 无 状态 应 用 。 男 一 组 是 有 状态 
(stateful) 、 宠 物 (pet) 、 具 名 (having name) 和 不 可 丢弃 (non- 
disposable) ， 它 们 则 都 可 用 于 称呼 有 状态 应 用 。 


和 目 Kubernetes 1.3 起 开始 通过 PetSet 控 制 器 支持 有 状态 应 用 ， 并 于 
1.5 版 本 中 将 其 重 命名 为 StatefulSet， 支 持 每 个 Pod 对 象 一 个 专 有 索引 、 
有 序 部 团 、 有 序 终 止 、 固 定 的 标识 符 及 固定 的 存储 卷 等 特性 。 不 过 在 
1.9 版 本 之 前 ， 它 一 直 处 于 beta 级 别 。 


9.1.3 ”StatefulSet 的 特性 


StatefulSet 是 Pod 资 源 控制 絮 的 一 种 实现 ， 用 于 部 署 和 扩展 有 状态 
应 用 的 Pod 资 源 ， 确 保 它 们 的 运行 顺序 及 每 个 Pod 资 源 的 唯一 性 。 其 与 
ReplicaSet 控 制 絮 不 同 的 是 ， 虽 然 所 有 的 Pod 对 象 都 基于 同一 个 spec 配 置 
所 创建 ， 但 StatefulSet 需 要 为 每 个 Pod 维 持 一 个 唯一 有 旦 固定 的 标识 符 ， 
必要 时 还 要 为 其 创建 专 有 的 存储 卷 。StatefulSet 主 要 适用 于 那些 依赖 于 
下 列 类 型 资源 的 应 用 程序 。 


.稳定 且 唯 一 的 网 络 标识 符 。 
-稳定 且 持 久 的 存储 。 

-有 序 、 优 雅 地 部 署 和 扩展 。 
-有 序 、 优 雅 地 删除 和 终止 。 
-有 序 而 自动 地 滚动 更 新 。 


一 般 来 说 ， 一 个 上 典型、 完整 可 用 的 StatefulSet 通 常 由 三 个 组 件 构 
成 : Headless Service、StatefulSet 和 volumeClaimTemplate。 其 中 ， 
Headless Service 用 于 为 Pod 资 源 标识 符 生 成 可 解析 的 DNS 资源 记录 ， 
StatefulSet 用 于 管控 Pod 资 源 ，volumeClaimTemplate 则 基于 静态 或 动态 
的 PV 供给 方式 为 Pod 资 源 提供 专 有 且 固 定 的 存储 。 


对 于 一 个 拥有 N 个 副本 的 StatefulSet 来 说 ， 其 Pod 对 象 会 被 有 序 创 
建 ， 顺 序 依次 是 {0...N-1}， 删 除 则 以 相反 的 顺序 进行 。 不 过 ， 
Kubernetes 1.7 及 其 之 后 的 版 本 也 文 持 并 行 管理 Pod 对 象 的 策略 。Pod 资 
源 的 名 称 格式 为 $ (statefulset name) -$ (ordinal) ， 例 如 ， 名 称 为 Web 
的 ReplicaSet 资 源 所 生成 的 Pod 对 象 的 名 称 依次 为 web-0、web-1、web-2 
等 ， 其 域名 后 级 可 由 相关 的 Headless 类 型 的 Service 资 源 给 出 ， 格 式 为 $ 
(service name) .$ (namespace) .svc.clusterlocal，clusterlocal 是 集群 默 


认 使 用 的 域名 。 


ReplicaSet 控 制 器 会 为 每 个 VolumeClaim 模 板 创建 一 个 专用 的 PV， 
它 会 从 模板 中 指定 的 StorageClass 中 为 每 个 PVC 创 建 PV， 未 指定 时 将 使 
用 默认 的 StorageClass 资 源 ， 而 如 果 和 存储 系统 不 支持 PV 的 动态 供给 ， 整 


需要 管理 员 事 先 创建 好 满足 需求 的 所 有 PV。 删 除 Pod 资 源 甚 至 是 
ReplicaSet 控 制 絮 并 不 会 删除 与 其 相关 的 PV 资源 以 确保 数据 安全 ， 它 需 
要 由 用 户 手 动 删 除 。 这 也 意味 着 ，Pod 资 源 被 重新 调度 至 其 他 节点 时 ， 
其 PV 及 数据 可 复 用 。Pod 名 称 、PVC 和 PV 关系 如 图 9-2 所 示 。 


ReplicaSet 也 文 持 规 模 扩 缩 容 操作 ， 扩 容 意味 着 按 索引 顺序 增加 更 
多 的 Pod 资 源 ， 而 缩 容 则 表示 按 逆序 依次 删除 索引 号 最 大 的 Pod 资 源 直 
到 规模 数量 满足 目标 设 定 值 。 执 行 扩 容 操作 时 ， 应 用 至 某 Pod 对 象 之 前 
必须 确保 其 前 的 每 个 Pod 对 象 都 已 经 就 绪 ， 反 之 ,终止 一 个 Pod 对 象 
时 ， 必 须 事先 确保 它 的 后 继 者 已 经 终止 完成 。 考 虑 到 不 少 的 有 状态 应 
用 不 支持 规模 的 安全 快速 缩减 ， 因 此 ，ReplicaSet 控 制 器 不 支持 缩 容 时 
的 并 行 操 作 ， 一 次 仅 能 终止 一 个 Pod 资 源 ， 以 免 导致 数据 论 误 。 这 通常 
也 意味 着 ， 存 在 错误 的 未 恢复 的 Pod 资 源 时 ，ReplicaSet 控 制 器 也 会 拒 
绝 局 动 缩 容 操作 。 此 外 ， 缩 容 操 作 导 致 的 Pod 资 源 终止 也 不 会 删除 与 其 
相关 的 PY， 以 确保 数据 安全 。 


| StatefulSet web | Pod web-0 一 pVvC a | mw | 
可 yak 一 


sie 一 ea 

I NS Pod web-1 PVC web-1l 一 
volumeClaim - 
a = = 


template 


Pod web-2 


图 9-2 ”Pod 名 称 、PVC 和 PV 


Kubernetes 目 1.7 版 本 起 还 支持 用 户 目 定义 更 新 策略 ， 该 版 本 兼容 文 

持 之 前 版 本 中 的 删除 后 更 新 (OnDelete) 策略 ， 以 及 新 的 滚动 更 新 策略 

(RollingUpdate) 。OnDelete 意 味 着 ReplicaSet 不 会 自动 更 新 Pod 资 源 除 
非 它 被 删除 而 激活 重建 操作 。RollingUpdate 是 默认 的 更 新 策略 ， 它 支 
持 Pod 资 源 的 自动 、 深 动 更 新 。 更 新 顺序 与 终止 Pod 资 源 的 顺序 相同 ， 
由 索引 号 最 大 的 资源 开始 ， 终 止 一 个 并 完成 其 更 新 ， 而 后 更 新 下 一 
个 。 另 外 ，RollingUpdate 还 文 持 分 区 (partition) 机 制 ， 用 户 可 基于 某 
个 用 于 分 区 的 索引 号 对 Pod 资 源 进 行 分 区 ， 所 以 大 于 等 于 此 索引 号 的 
Pod 资 源 会 被 深 动 更 新 ， 如 图 9-3 所 示 。 而 小 于 此 索引 号 的 Pod 资 源 则 不 
会 被 更 新 ， 即 便 是 此 范围 内 的 某 Pod 资 源 被 删除 ， 它 也 一 样 会 被 基于 旧 
版 本 的 Pod 模 板 重建 。 


StatefulSet web 
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图 9-3 ”ReplicaSset 分 区 滚动 更 新 


大 给 定 的 分 区 号 大 于 副本 数量 ， 则 意味 着 不 会 有 Pod 资 源 索 引号 大 
于 此 分 区 号 ， 所 有 的 Pod 资 源 均 不 会 被 更 新 ， 对 于 暂 存 发 布 、 金 丝 牧 发 
布 或 分 段 发 布 来 说 ， 这 也 是 有 用 的 设 定 。 


9.2 StatefulSet 基 础 应 用 


本 贡 将 基于 StorageClass 及 其 相关 的 PV 动态 供给 功能 创建 一 个 
stateful 资 源 示例 ， 并 验证 它 的 各 种 特性 。 


9.2.1 创建 StatefulSet 对 象 


如 前 所 述 ， 一 个 完整 的 StatefulSet 控 制 器 需要 由 一 个 Headless 
Service 、 个 Statefulget 和 一 个 volumeClaimTemplate 组 成 。 5s 其中， 
Headless Service 用 于 为 Pod 资 源 标识 符 生 成 可 解析 的 DNS 资源 记录 ， 
StatefulSet 用 于 管控 Pod 资 源 ，volumeClaimTemplate 则 基于 静态 或 动态 
的 PV 供 给 方式 为 Pod 资 源 提供 专 有 且 固 定 的 存储 ， 如 下 面 的 资源 清单 
中 的 定义 所 示 : 


apiVersion: v1 
kind: Service 
metadata: 
name: myapp-svc 
Jabels: 
app: myapp-svc 
spec: 
ports: 
- port: 80 
name: web 
clusterIP: None 
selector: 
app: myapp-pod 
apiVersion: apps/vi1 
kind: StatefulSet 
metadata: 
name: myapp 
spec: 
serviceName: myapp-svc 
replicas: 2 
selector: 
matchLabels: 
app: myapp-pod 
template: 
metadata: 
Jabels: 
app: myapp-pod 
spec: 

containers: 

- name: myapp 
image: ikubernetes/myapp:v5 
ports: 

- containerPort: 80 
name: web 
volumeMounts: 
- name: myappdata 
mountPath: /usr/share/nginx/html 
volumeClaimTemplates: 
- metadata: 

name: myappdata 

spec: 


accessModes: [ "Readwriteonce"” | 
storageClassName: "gluster-dynamic" 
resources: 
requests: 
storage: 26Gi 


上 面 示例 中 的 配置 定义 在 statefulset-demo.yaml 文 件 中 。 由 于 
StatefulSet 资 源 依 赖 于 一 个 事先 存在 的 Headless 类 型 的 Service 资 从 源 ， 因 
pe 这 里 首先 定义 了 一 个 名 为 myapp- svc 的 Headless Service 资 各 源 ， 用 于 
为 关联 到 的 每 个 pod 资 源 创建 DNS 资源 记录 。 接 着 定义 了 一 个 名 为 
myapp 的 StatefulSet 资 容 源 ， 它 通过 Pod 模 板 创建 了 两 个 pod 资 源 副本 ， 并 
基于 volumeClaimTemplates (存储 卷 申 请 模板 ) 加 gluster- dynamic 存 储 
0 从 而 为 每 个 Pod 资 源 提供 大 小 为 2GB 的 专用 存储 


事实 上 ， 定 义 StatefulSet 资 源 时 ，spec 中 必须 要 崩 套 的 字段 
为 “serviceName” 和 “template”"， 用 于 指定 关联 的 Headless Service 和 要 使 
用 的 Pod 模 板 , “volumeClaimTemplates” 


字段 用 于 为 Pod 资 从 源 创建 专 有 存储 苍 PVC 模 板 ， 它 可 内 磐 使 用 的 字 
人 Claim 资 源 的 可 用 字段 ， 对 StatefulSet 资 源 为 可 
选 字段 。 


在 依赖 的 存储 类 满足 条 件 之 后 ， 即 可 创建 清单 中 定义 的 相关 资 


源 : 


~]$ kubectl1 apply -f statefulset-demo.yaml 
service "myapp-svc" created 
statefulset.apps "myapp" created 


默认 情况 下 ，StatefulSet 控 制 妖 以 串 行 的 方式 创建 各 Pod 副 本 ， 如 
果 想 要 以 并 行 方式 创建 和 删除 Pod 资 源 ， 则 可 以 设 
定 .spec.podManagementPolicy 字 段 的 值 为 Parallel”， 默认 值 
为 “OrderedReady”。 。 使 用 默认 的 顺序 创建 策略 时 ， 可 以 使 用 下 面 的 命 
令 观察 相关 Pod 资 源 的 顺 次 生成 过 程 : 


~]$ kubectl1 get pods -1 pb myapp-pod -w 

NAME READY STATU RESTARTS AGE 
myapp-0 0/1 ei 0 Os 
myapp-0 0/1 ContainerCreating 0 Os 


myapp-0 1/1 Running 0 42S 
myapp-1 0/1 Pending 0 Os 
myapp-1 0/1 ContainerCreating 0 Os 
myapp-1 1/1 Running 0 14S 


待 所 有 的 Pod 资 源 都 创建 完成 之 后 ， 可 以 在 StatefulSet 资 源 的 相关 
状态 中 看 到 相关 pod 次 帘 源 的 束 绪 信息 : 


~]$ kubect1 get statefulsets myapp 
NAME DESIRED CURRENT AGE 
myapp 2 2 10m 


若 上 述 资 源 的 相关 信息 一 切 正 常 ， 则 StatefulSet 资 源 myapp 已 然 束 
绪 ， 其 服务 也 可 由 其 他 依赖 方 所 调用 。 


9.2.2 ”Pod 资 源 标识 符 及 存储 卷 


由 StatefulSet 挥 制 絮 创建 的 Pod 资 源 拥有 固定 、 唯 一 的 标识 和 专用 
存储 着 ， 即 便 重 痢 调 度 或 终止 后 重建 ， 其 名 称 也 依然 傈 持 不 变 ， 且 此 
前 的 存储 卷 及 其 数据 不 会 丢失 。 


1.Pod 资 源 的 固定 标识 符 


如 前 所 述 ， 由 StatefulSet 控 制 器 创建 的 Pod 对 象 拥有 固定 且 唯 一 的 
标识 符 ， 它 们 基于 唯一 的 索引 序号 及 相关 的 StatefulSet 对 象 的 名 称 而 生 
成 ， 格 式 为 “<statefulset name>-<ordinal index>”， 如 下 面 的 命令 结果 所 
不 Rs 名 称 分 别 为 myapp-0 和 myapp-1， 其 中 myapp 为 控制 
铬 有 的 名 称 : 


~]$ kubectl1 get pods -1] app=myapp-pod 


NAME READY STATUS RESTARTS AGE 
myapp-0 1/1 Running 0 4m 
myapp-1 1/1 Running 0 3m 


Pod 资 源 的 主机 名 同 其 资源 名 称 ， 因 此 也 是 带 索 引 序 号 的 名 称 格 
式 ， 如 下 面 的 命令 结果 所 示 : 


~]$ for i in 0 1; do kubectl exec myapp-$i -- sh -c 'hostname'; done 
myapp-0 
myapp-1 


这 些 名 称 标识 会 由 StatefulSet 资 源 相 关 的 Headless Service 资 源 创建 
为 DNS 资源 记录 ， 其 域名 格式 为 $ (service name) .$ 
(namespace) .svc.cluster.local， 其 中 “cluster.local”* 是 集群 的 默认 域 
名 。 在 Pod 资 源 创 建 后 ， 与 其 相关 的 DNS 资源 记录 格式 为 “$ 
(pod name) .$ (service name) .$ (namespace) .svc.cluster.local”, 


例如 前 面 创建 的 两 个 Pod 资 源 的 资源 记录 为 myapp-0. 


myapp-svc.default.svc.clusterlocal 和 myapp-1.myapp- 
svc.default.svc.cluster.local。 下 面 再 创建 一 个 临时 的 Pod 资 源 ， 并 通过 


其 交互 式 接口 测试 上 述 两 个 名 称 的 解析 ， 其 中 粗 体 部 分 标识 的 内 容 为 


A 
要 运行 的 测试 命令 : 


~]$ kubectl run -it --image busybox dns-client --restart=Never --rm /bin/sh 
If you don't see a command prompt, try pressing enter. 

/ # nslookup myapp-0.myapp-svc 

Server: 10.96.0.10 

Address 1: 10.96.0.10 kube-dns.kube-system,.svc.cluster.1local 


Name: myapp-0.myapp-svc 

Address 1: 10.244.1.25 myapp-0.myapp-svc.default.svc.cluster.1local 
/ # nslookup myapp-1.myapp-svc 

Server: 10.96.0.10 

Address 1: 10.96.0.10 kube-dns.kube-system,.svc.cluster.1local 


Name: myapp-1.myapp-svc 

Address 1: 10.244.2.23 myapp-1.myapp-svc.default.svc.cluster.1local 
/ # nslookup myapp-svc 

Server: 10.96.0.10 

Address 1: 10.96.0.10 kube-dns.kube-system,.svc.cluster.1local 


Name: myapp-svc 

Address 1: 10.244.1.25 myapp-0.myapp-svc.default.svc.cluster.1local 
Address 2: 10.244.2.23 myapp-1.myapp-svc.default.svc.cluster.1local 
/ # 


Headless Service 资 源 借助 于 SRV 记 录 来 引用 真正 提供 服务 的 后 端 
Pod 资 源 的 主机 和 名称， 进行 指 问 包含 Pod IP 地 址 的 记录 条 目 。 此 外 ， 由 
StatefulSet 探 制 右 管控 的 Pod 资 源 终止 后 会 由 控制 右上 和 目 动 进行 重建 ， 虽 
然 其 IP 地 址 存在 变化 的 可 能 性 ， 但 它 的 名 称 标识 在 重建 后 会 保持 不 
变 。 例 如 ， 在 另 一 个 终端 中 删除 Pod 资 源 myapp-1: 


~]$ kubectl1 delete pods myapp-1 
pod "myapp-1" deleted 


删除 完成 后 控制 硕 将 随 之 开始 重建 Pod 资 源 ， 由 下 面 的 命令 结 采 
可 知 ， 其 名 称 标识 符 的 确 未 发 生 改 变 : 


~]$ kubectl] get pods -1 app=myapp-pod 
TUS 


NAME READY STA RESTARTS AGE 
myapp-0 1/1 Running 0 8m 
myapp-1 0/1 ContainerCreating 0 0S 


Pod 资 源 重建 完成 后 ， 表 次 由 此 前 创建 的 交互 式 测试 终端 举 试 进 
行 名 称 解 析 测 试 。 由 下 面 的 命令 结果 可 知 ，Pod 资 源 的 DNS 标识 亦 未 


发 生 改变 ， 但 其 IP 地 址 会 指向 重建 后 的 Pod 资 源 地 址 : 


/ # nslookup myapp-1.myapp-svc 
Server: 10.96.0.10 
Address 1: 10.96.0.10 kube-dns.kube-system,.svc.cluster.1local 


Name: myapp-1.myapp-svc 
Address 1: 10.244.3.33 myapp-1.myapp-svc.default.svc,.cluster.1local 
/ # 


因此 ， 当 客户 端 尝试 癌 StatefulSet 资 源 的 Pod 成 员 发 出 访问 请 求 
时 ， 应 该 针对 HeadlessService 资 源 的 CNAME (myapp- 
svc.default.svc.cluster.local) 记录 进行 ， 它 指 癌 的 SRV 记 录 包 含 了 当前 
处 于 束 绪 状态 的 Pod 资 源 。 当 然 ， 若 在 配置 Pod 模 板 时 定义 了 Pod 资 源 
的 liveness probe 和 readiness probe， 考 虑 到 名 称 标识 固定 不 变 ， 也 可 以 
让 客户 端 直接 向 SRV 资 源 记 录 (myapp-0.myapp-svc 和 myapp- ed 
svc) 发 出 请 求 。 


2.Pod 资 源 的 专 有 存储 卷 


前 面 的 StatefulSet 资 源 示例 中 ， 控 制 絮 过 volumeClaimTemplates 
四 pod 守信 关联 一 PVC 和 它们 分 别 绑 定 了 一 个 动 
仿 供 给 的 PVX 


~]$ kubectl1 get pvc -1 app=myapp-pod -o \ 
custom-columns=NAME:metadata.name,VOLUME: spec.volumeName, STATUS: status.phase 
NAME VOLUME STATUS 
myappdata-myapp-0 pvc-405cf708-2ddc-11e8-b246-000c29be4e28 Bound 
myappdata-myapp-1 pvc-495f87c8-2ddc-11e8-b246-000c29be4e28 Bound 


PVC 存 储 卷 由 Pod 资 源 中 的 容器 挂 载 到 了 /usr/share/nginx/html 目 
录 ， 此 为 容器 应 用 的 Nginx 进 程 默 认 的 文档 根 路 径 。 下 面 通 过 kubect 
0 贷 源 于 此 目录 中 生成 一 个 测试 页 面 ， 用 于 存储 卷 持 
济 斌 \: 


~]$ for i in 0 1; do kubectl exec myapp-$i -- sh -c \ 
"echo $(date), Hostname: $(hostname) > /usr/share/nginx/html/index.html'; 
done 


接 下 来 基于 一 个 由 cirros 镜 像 启动 的 客户 端 Pod 对 象 进 行 访问 测 
试 ， 这 样 便 可 通过 其 DNS 名 称 引 用 每 个 Pod 资 源 : 


~]$ kubectl run -it --image cirros client --restart=Never --rm /bin/sh 
If you don't see a command prompt, try pressing enter. 

/ # curl myapp-0.myapp-svc 

Fri Mar 23 07:00:46 UTC 2018, Hostname: myapp-0 

/ # curl myapp-1.myapp-svc 

Fri Mar 23 07:00:46 UTC 2018, Hostname: myapp-1 

/ # 


删除 StatefulSet 控 制 器 的 Pod 资 源 ， 其 存储 卷 并 不 会 被 删除 ， 除 非 
用 广 或 管理 员 手 动 操作 移 除 操作 。 因此 ， 在 另 一 个 终端 中 删除 Pod 资 
源 myapp-0， 经 由 StatefulSet 控 制 需 重建 后 ， 它 依然 会 关联 到 此 前 的 
PVC 存 储 卷 上 ， 且 此 前 数据 依旧 可 用 : 


~]$ kubect1 delete pods myapp-0 
pod "myapp-0" deleted 


男 一 个 终端 中 监控 到 的 删除 及 重建 过 程 如 下 面 的 命令 及 其 结 采 所 


和 小 : 


~]$ kubectl1 get pods -1 app=myapp-pod -w 
NAME READY STATUS RESTARTS AGE 


myapp-0 1/1 Running 0 1h 
myapp-1 1/1 Running 0 1h 
myapp-0 0/1 Terminating 0 1h 
myapp-0 0/1 Pending 0 Os 
myapp-0 0/1 Pending 0 Os 
myapp-0 0/1 ContainerCreating 0 Os 
myapp-0 1/1 Running 0 11S 


而 后 通过 测试 用 的 Pod 资 源 接口 再 次 对 其 进行 访问 测试 ， 由 如 下 
内 容 可 知 ， 存 储 卷 是 复 用 此 前 的 那个 ; 


/ # curl myapp-0.myapp-svc 
Fri Mar 23 07:00:46 UTC 2018, Hostname: myapp-0 
/ # 


由 此 表明 ， 重 建 的 Pod 资 源 被 重 狐 调度 至 哪个 节操 ， 此 前 的 PVC 资 
源 丈 会 被 分 配 至 哪个 节点 ， 这 样 吏 真正 实现 了 才 据 的 持 交 化 


9.3 StatefulSet 资 源 扩 缩 容 


StatefulSet 资 源 的 扩 缩 容 与 Deployment 资 源 相似 ， 即 通过 修改 资源 
的 副本 数 来 改动 其 目标 Pod 资 源 数量 。 对 StatefulSet 资 源 来 说 ，kubectd 
scale 和 kubectl patch 命 令 均 可 实现 此 功能 ， 也 可 以 使 用 kubectl edit 命 令 
或 者 在 修改 配置 文件 之 后 ， 由 kubectlapply 命 令 重 
新 声明 。 


例如 ， 下 面 的 命令 即 能 将 myapp 中 的 Pod 副 本 数量 扩展 至 6 个 : 


~]$ kubect1 scale statefulset myapp --replicas=6 
statefulset.apps "myapp" scaled 


StatefulSet 资 源 的 扩展 过 程 与 创建 过 程 的 Pod 资 源 生 成 策略 相同 ， 
默认 为 顺 次 进行 ， 而 且 其 名 称 中 的 序号 也 将 以 现 有 Pod 资 源 的 最 后 一 
个 序号 向 后 进行 : 


~]$ kubectl1 get pods -1 app=myapp-pod -w 
S 


NAME READY STATU RESTARTS AGE 
myapp-0 1/1 Running 0 5m 
myapp-1 1/1 Running 0 4m 
myapp-2 0/1 ContainerCreating 0 10s 
myapp-2 1/1 Running 0 25S 
0 10s 


myapp-3 0/1 ContainerCreating 


与 扩容 操作 相对 ， 执 行 缩 容 操作 只 需要 将 其 副本 数量 调 低 即 可 ， 
例如 ， 这 里 可 使 用 kubect patch 命 令 将 StatefulSet 资 源 myapp 的 副本 数量 
修补 为 3 个 : 


~]$ kubectl1 patch statefulset myapp -p '{"spec":{"replicas":3}}' 
statefulset.apps "myapp" patched 


缩减 规模 时 终止 Pod 资 源 的 默认 策略 也 以 Pod 顺 序号 敢 序 逐一 进 
行 ， 直 到 余下 的 数量 满足 目标 为 止 : 


~]$ kubect1 get pods -1 app=myapp-pod -w 
ATUS 


NAME READY ST RESTARTS AGE 
myapp-0 1/1 Running 0 7m 
myapp-1 1/1 Running 0 6m 
myapp-2 1/1 Running 0 2m 
myapp-3 1/1 Running 0 2m 
myapp-4 1/1 Running 0 1m 
myapp-5 1/1 Running 0 1m 
myapp-5 1/1 Terminating 0 1m 
myapp-5 0/1 Terminating 0 1m 
myapp-4 1/1 Terminating 0 2m 
myapp-4 0/1 Terminating 0 2m 
myapp-3 1/1 Terminating 0 2m 
myapp-3 0/1 Terminating 0 2m 


另外， 终止 Pod 资 源 后 ， 其 存储 卷 并 不 会 被 删除 ， 因 此 缩减 规模 
后 大 再 将 其 扩展 回来 ， 那么 此 前 的 数据 依然 可 用 ， 且 Pod 资 源 名 称 保 


持 不 变 。 


9.4 StatefulSet 资 源 升 级 


自 Kubernetes 1.7 版 本 起 ，StatefulSet 资 源 支 持 自动 更 新 机 制 ， 其 更 
狐 策 略 将 由 spec.updateStrategy 字 段 定 义 ， 默 认为 RollingUpdate， 即 滚 
动 更 新 。 男 一 个 可 用 策略 为 OnDelete， 


即 删除 Pod 资 质 源 重建 以 完成 更 新 ， 这 也 是 Kubernetes 1.6 及 之 前 版 
本 唯一 可 用 的 更 新 策略 。 Sate lo 下 源 的 更 新 中 制 可 用 于 更 新 Pod 资 
源 中 的 容器 镜像 、 标 签 、 注 解 和 系统 资源 配额 等 


9.4.1 滚动 更 新 


ee 的 Pod 资 源 以 逆序 的 形式 从 其 最 大 索引 
编号 的 Pod 资 源 逐 一 进行 ， 它 在 终止 一 个 Pod 资 源 、 更 新 资 筑 源 并 待 其 让 了 
绪 后 启动 更 新 下 一 个 资源 ， 即 索引 号 比 当前 号 小 1 的 Pod 资 源 。 对 于 主 
从 复制 类 的 集群 应 用 来 说 ， 这 样 也 保证 起 主 节点 作用 的 Pod 资 源 最 
后 进行 更 新 ， 确 保 兼容 性 。 


StatefulSet 的 默认 更 新 策略 为 滚动 更 新 ， ec get 
statefulset NAME” 命 令 中 的 输出 可 以 获取 相关 的 信息 ，myapp 控 制 妖 的 
输出 如 下 所 示 : 


updatestrategy: 
rollingUpdate: 
partition: 0 
type: RollingUpdate 


更 新 Pod 中 的 容 右 镜像 可 以 使 用 "kubectl set image” 命 令 进行 ， 例 如 
下 面 的 命令 可 将 myapp 控 制 锅 下 的 Pod 资 源 镜 像 版 本 升级 
为 “ikubernetes/myapp: v6”: 


~]$ kubectl1 set image statefulset myapp myapp=ikubernetes/myapp:v6 
statefulset.apps "myapp" image updated 


更 新 操作 过 程 ， 可 在 男 一 终 并 中 使 用 如 下 命令 进行 监控 ， 其 逆序 
操作 Pod 资 源 的 过 程 如 下 面 的 命令 仿 结 果 所 示 ; 


~]$ kubectl] get pods -1 app=myapp-pod -w 


NAME READY STATUS RESTARTS AGE 
myapp-0 1/1 Running 0 11m 
myapp-1 1/1 Running 0 11m 
myapp-2 1/1 Running 0 6m 
myapp-2 1/1 Terminating 0 7m 
myapp-2 0/1 Terminating 0 7m 
myapp-2 0/1 Pending 0 Os 
myapp-2 0/1 ContainerCreating 0 Os 
myapp-2 1/1 Running 0 11S 
myapp-1 1/1 Terminating 0 11m 
myapp-1 0/1 Terminating 0 11m 
myapp-1 0/1 Pending 0 Os 


myapp-1 0/1 ContainerCreating 0 2s 
myapp-1 1/1 Running 0 18S 
myapp-0 1/1 Terminating 0 12m 
myapp-0 0/1 Terminating 0 12m 
myapp-0 0/1 Pending 0 Os 
myapp-0 0/1 ContainerCreating 0 Os 
myapp-0 1/1 Running 0 11S 


ge ， 获 取 每 个 Pod 资 源 中 的 镜像 文件 版 本 即 可 验证 其 


~]$ for i in 0 1 2; do kubectl get po myapp-$i \ 
--template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'; echo; 
done 
ikubernetes/myapp:v6 
ikubernetes/myapp:v6 
ikubernetes/myapp:v6 


. 另外 ， 用 户 也 可 以 使 用 “kubectl rollout status” 命 令 跟 中 StatefulSet 
资源 滚动 更 新 过 程 中 的 状态 信息 。 


9.4.2 ”上 芹 存 更 新 哥 作 


当 用 户 需 要 设 定 一 个 更 新 操作 ， 但 又 不 希望 它 立 即 执行 时 ， 可 将 
更 新 操作 予以 “ 暂 存 ”， 竺 条 件 满足 后 再 手动 触发 其 执行 更 新 。 
StatefulSet 资 源 的 分 区 更 新 机 制 能 够 实现 此 项 功 能 。 在 设 定 更 新 操作 
之 前 ， 将 .spec.update-Strategy.rollingUpdate.partition 字 上 段 的 值 设置 为 
Pod 资 源 的 副本 数量 ， 即 比 Pod 资 源 的 最 大 索引 号 大 1， 这 就 意味 着 ， 
所 有 的 Pod 资 源 都 不 会 处 于 可 直接 更 新 的 分 区 之 内 (如 图 9-4 所 示 ) ， 
那么 于 其 后 设 定 的 更 新 操作 也 就 不 会 真正 执行 ， 直 到 用 户 降 低 分 区 编 


号 至 现 有 Pod 资 源 索 引号 范围 之 内 。 
Pod myapp-0 


Pod myapp-1 


Pod myapp-2 


图 9-4 暂 存 更 新 


下 面 测试 深 动 更 新 的 暂 存 更 新 操作 ， 前 先 将 StatefulSet 资 源 myapp 
的 滚动 更 新 分 区 值 设 定 为 3: 


StatefulSet myapp 
replicas: 3 


Pod 
myapp:v6 


partition=3 


一 4 一 一 


~]$ kubect1 patch statefulset myapp \ 
-p '{"spec":{"updateSstrategy":{"rollingUpdate":{"partition":3}}}}" 
statefulset.apps "myapp" patched 


而 后 ， 将 myapp 控 制 器 的 Pod 资 源 镜像 版 本 更 新 
为 “ikubernetes/myapp: V7”: 


~]$ kubectl1 set image statefulset myapp myapp=ikubernetes/myapp:v7 
statefulset.apps "myapp" image updated 


接 看 检测 各 Pod 资 源 的 镜像 文件 版 本 信息 ， 可 以 发 现 其 版 本 并 未 
发 生 改变 : 


$ kubectl1 get pods -1 app=myapp-pod \ 
-0 cusStom-columns=NAME:metadata.name, IMAGE: spec.containers[0].image 
NAME IMAGE 
myapp-0 ikubernetes/myapp:v6 
myapp-1 ikubernetes/myapp:v6 
myapp-2 ikubernetes/myapp:v6 


此 时 ， 即 便 删 除 某 Pod 资 源 ， 它 依然 会 基于 旧 的 版 本 镜像 进行 重 
° 例如 ， 下 面 首先 删除 了 Pod 对 象 myapp-1， 随 后 待 其 重建 操作 启动 
后 ， 再 获取 与 其 相关 的 镜像 信息 ， 结 果 依 然 显 示 了 旧 的 版 本 : 


~]$ kubectl1 delete pods myapp-1 
pod "myapp-1" deleted 
~]$ kubectl1 get pods myapp-1 \ 
-0 cusStom-columns=NAME:metadata.name, IMAGE: spec.containers[0].image 
NAME IMAGE 
myapp-1 ikubernetes/myapp:v6 


由 此 可 见 ， 暂 存 状态 的 更 新 操作 对 所 有 的 Pod 资 源 均 不 产生 影 
H。 
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将 处 于 和 暂 存 状态 的 更 新 操作 的 partition 定 位 于 Pod 资 源 的 最 大 索引 
号 ， 即 可 放出 一 只 金 丝 雀 ， 由 其 测试 第 一 轮 的 更 新 操作 ， 在 确认 无 误 
> 
新 操作 。 


将 9.4.2 节 暂停 的 更 新 Statefulset 控 制 器 myapp 资 源 的 分 区 号 设置 为 
pod 资源 的 最 大 索引 号 2， 将 会 触发 myapp-2 的 更 新 操作 : 


~]$ kubectl1 patch statefulset myapp -p '{"spec":{"updateSstrategy": 
{"rollingUpdate":{"partition":2}}}}" 
statefulset.apps "myapp" patched 


其 执行 结 末 如 图 9-5 所 示 。 


StatefulSet myapp 


Pod myapp-0 
Pod myapp-1 


ss partition=2 


replicas: 3 


Pod 
myapp:v6 


图 9-5 ” 金 丝 省 发 布 


竺 其 更 新 完成 后 ， 检 测 所 有 Pod 资 源 使 用 的 镜像 文件 版 本 ， 对 比 
出 ， 可 以 看 出 其 更 新 操作 再 次 暂停 于 myapp-2 的 更 新 操 
元 日: 


~]$ kubectl1 get pods -1 app=myapp-pod \ 
-0 CusStom-columns=NAME:metadata.name, IMAGE: spec.containers[0].image 
NAME IMAGE 


myapp-0 ikubernetes/myapp:v6 
myapp-1 ikubernetes/myapp:v6 
myapp-2 ikubernetes/myapp:v7 


此 时 ， 位 于 非 更 新 分 区 内 的 其 他 Pod 资 源 仍 不 会 被 更 新 到 新 的 镜 
像 版 本 ， 哪 名 它们 被 删除 后 重建 亦 是 如 此 。 


9.4.4 “分 段 更 新 


金 缘 省 安然 度 过 测试 阶段 之 后 ， 用 户 便 可 启动 后 续 其 他 Pod 资 源 的 
更 新 操作 。 在 等 更 新 的 Pod 资 源 数量 较 少 的 情况 下 ， 直 接 将 partition 属 
性 的 值 设置 为 0， 它 将 逆序 完成 后 续 所 有 Pod 资 源 的 更 新 。 而 当 待 更 新 
的 Pod 资 源 较 多 时 ， 用 户 也 可 以 将 Pod 资 源 以 线性 或 指数 级 增长 的 方式 
来 分 阶段 完成 更 新 操作 ， 操 作 过 程 无 非 是 分 步 更 新 partition 属 性 值 ， 例 
如 ， 将 myapp 控 制 硕 的 分 区 号 码 依次 设置 为 1、0 以 完成 剩余 Pod 资 源 的 
线性 分 步 更 新 ， 如 图 9-6 所 示 。 


replicas: 3 J patrtition=1 replicas: 3 
I 
图 9-6 分 阶段 更 新 
待 更 新 全 部 完成 后 ， 用 户 便 可 根据 需求 筹划 下 一 轮 的 更 新 操作 。 


StatefulSet myapp 


partition=0 


StatefulSet myapp 


9.4.5 ”其 他 话题 


同 其 他 类 型 的 Pod 控 制 絮 资源 类 似 ，StatefulSet 也 支持 级 联 或 非 级 
联 的 删除 操作 。 默认 的 删除 类 型 为 级 联 删 除 ， 即 同时 删除 StatefulSet 和 
相关 的 Pod 资 源 。 若 要 执行 非 级 联 删 除 ， 为 删除 命令 使 用 “-- 
cascade=false”j 选 项 即 可 。 


另外 ，StatefulSet 探 制 右 管理 Pod 资 源 的 策略 除了 默认 的 
OrderedReady 《〈 顺 次 创建 及 逆序 删除 ) 之 外 ， 还 文 持 并 行 的 创建 和 删 
除 操作 ， 即 同时 创建 所 有 的 Pod 资 源 以 及 同时 删除 所 有 的 Pod 资 源 ， 完 
成 这 一 点 ， 只 需要 将 spec.podManagementPolicy 字 段 的 值 设置 为 Parallel 
即 可 ， 不 过 对 于 有 角色 之 分 的 分 布 式 应 用 来 说 ， 为 了 保证 数据 安全 可 
靠 ， 建 议 使 用 默认 策略 ， 除 非 数 据 完整 性 是 可 以 不 用 考虑 在 内 的 因 


局 、 


另外 ， 不 同 的 有 状态 应 用 的 运 维 操作 过 程 差 别 巨大 ， 因 此 
StatefulSet 探 制 硕 本 叶 几 乎 无 法 为 此 种 类 型 的 应 用 提供 完善 的 通用 管理 
控制 机 制 ， 现 实 中 的 各 种 有 状态 应 用 通常 是 使 用 专用 的 目 定义 控制 器 
专门 封 痛 特定 的 运 维 操作 流程 ， 这 些 目 定 义 探 制 器 有 时 也 被 统一 称 为 
Operator， 这 些 内 容 将 在 后 面 的 章节 介绍 。 


9.5 案例 : etcd 集 群 


Kubernetes 的 所 有 对 象 都 需要 持久 化 存储 于 etcd 存 储 系 统 中 ， 以 确 
保 系 统 重启 或 故障 恢复 后 能 将 它们 予以 还 原 。 


etcd 是 一 个 分 布 式 键 值 数据 存储 系统 ， 具 有 可 靠 、 快 速 、 强 一 臻 
性 等 特性 ， 它 通过 分 布 式 锁 、leader 选 举 和 写 屏 障 (write barriers) 来 
实现 可 靠 的 分 布 式 协作 。 因 此 ，Kubernetes 系 统管 理 员 应 该 将 etcd 部 署 
为 集群 工作 模型 ， 以 实现 其 服务 高 可 用 ， 并 提供 更 好 的 性 能 表现 。 


etcd 将 键 存储 于 层级 组 织 的 键 空间 中 ， 这 使 得 它 看 起 来 非常 类 似 
于 文件 系统 的 倒置 树 状 结构 ， 于 是 ， 它 的 每 个 键 要 么 是 一 个 包含 有 其 
他 键 的 目 示 ， 要 么 是 一 个 全 有 数据 的 利 规 键 。Kubernetes 将 其 所 有 数 
据 存 储 于 etcd 的 mregistry 目 孙 中 ， 虽 然 API Server 是 以 JSON 格 式 组 织 数 
据 资 源 对 象 ， 但 对 于 底层 使 用 etcd 存 储 系 统 的 场景 来 说 ， 它 们 可 类 比 
为 存储 于 文件 系统 内 的 JSON 文 件 中 。 另 外 ，Kubernetes 的 系统 组 件 
中 ， 仅 API Server 直 接 与 etcd 进 行 通 信 ， 其 他 所 有 组 件 的 数据 读 写 操作 
都 要 经 由 API Serverj 进 行 ， 从 而 确保 了 数据 的 高 度 一 致 性 。 


在 分 布 式 模 型 中 ，etcd 采 用 raft 算 法 ， 实 现 了 分 布 式 系统 数据 的 可 
用 性 和 一 致 性 。 若 发 生 网 络 分 区 或 节点 故障 ， 则 raft 算 法 就 会 通过 
quorum 机 制 处 理 集群 状态 转移 ， 其 中 成 员 数 量 大 于 半数 的 一 方 可 继续 
工作 ， 铬 leader 存 在 ， 则 它们 可 继续 提供 读 写 服务 ， 否 则 就 要 选举 出 新 
的 leader， 并 旦 在 此 期 间 写 操作 是 被 禁止 的 ， 而 成 员 数 量 少 于 半数 的 市 
点 将 停止 任何 的 写 入 操作 。 本 将 描述 如 何 于 Kubernetes 集 群 中 基于 
StatefulSet 探 制 器 托管 部 署 一 个 分 布 式 的 etcd 集 群 ， 它 只 是 一 个 部 署 示 
例 ， 并 不 会 取代 Kubernetes 系 统 现 有 的 etcd。 


9.5.1 创建 Service 资 源 


StatefulSet 资 源 依赖 于 Headless Service 为 各 Pod 资 源 提供 名 称 解 析 
服务 ， 其 他 Pod 资 源 可 直接 使 用 DNS 名 称 来 获取 相关 的 服务 ， 如 etcd- 
0.etcd 、 ed 1. stod 等 ， 下 面 的 资源 清单 《etcd-services. yaml) 中 定义 的 
第 一 个 任 源 etcd 就 是 此 类 的 Service 资 源 。 第 二 个 名 为 etcd- 
Service 次 务 源 是 一 个 正常 的 Service， 它 拥 有 ClusterIP， 并 可 通 
NodePort 回 Kubernetes 集 群 外 部 的 etcd 客 户 端 提 供 服 务 : 


apiVersion: v1 
kind: Service 
metadata.: 
name: etcd 
annotations: 
# Create endpoints also if the related pod isn't ready 
service.alpha.kubernetes.io/tolerate-unready-endpoints: "true" 
spec: 
ports: 
- port: 2379 
name: client 
- port: 2380 
name: peer 
clusterIP: None 
selector: 
app: etcd-member 


apiVersion: v1 
kind: Service 
metadata: 

name: etcd-client 

spec: 

ports: 

- name: etcd-client 
port: 2379 
protocol: TCP 
targetPort: 2379 

selector: 
app: etcd-member 

type: NodePort 


首先 创建 上 述 两 个 Service 对 和 象 


~]$ kubectl1 apply -f etcd-services.yaml 
service "etcd-svc" created 
service "etcd-client" created 


而 后 ， 可 于 default 名 称 空 间 中 看 到 如 下 两 个 Service 资 源 记录 : 


~]$ kubect1 get Svc -1 app=etcd 


NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE 
etcd ClusterIP None <none> 2379/TCP, 2380/TCP 5S 
etcd-client NodePort 10.244.60.53 <none> 2379:30290/TCP 5s 


i 以 看 出 ，etcd-client 通 过 10.99.175.53 向 客户 端 
提供 服务 ， 它 是 一 个 标准 类 型 的 Service 资 源 ， 类 型 为 NodePort， 可 通 
过 各 工作 节点 的 30290 册 口 将 服务 暴露 到 集群 外 部 。 。 服 务 类 型 的 资源 创 
建 完成 后 ， 接 下 来 便 可 创建 StatefulSet 控 制 器 ， 构 建 分 布 式 etcd 集 群 。 


9.5.2 etcd StatefulSet 


etcd 依 赖 于 持久 存储 设备 保存 数据 ， 这 里 为 其 配置 了 使 用 自 定 义 
的 、 具 有 动 态 PV 供 给 切 能 的 gluster-dynamic 存 储 类 为 各 Pod 资 源 的 PVC 
提供 存储 后 端 ， 大 小 可 由 用 户 按 需 求 进行 定义 。 另 外 ，etcd 镜 像 文件 
的 版 本 也 可 由 用 全 修改 为 与 实际 需求 匹配 的 版 本 ， 如 3.3.1 等 ， 不 过 
StatefulSet 本 就 文 持 日 动 更 新 机 制 ， 用 户 也 可 以 于 必要 时 启动 更 新 机 制 
切换 其 镜像 版 本 。 下 面 是 定义 在 etcd-statefulset.yaml 文 件 中 的 配置 示 
例 ， 它 定义 了 一 个 名 为 etcd 的 StatefulSet 资 源 : 


apiVersion: apps/vi1 
kind: StatefulSet 
metadata: 
name: etcd 
labels: 
app: etcd 
spec: 
serviceName: etcd 
# changing replicas value will require a manual etcdct] member remove/add 
# command (remove before decreasing and add after increasing) 
replicas: 3 
selector: 
matchLabels: 
app: etcd-member 
template: 
metadata: 
name: etcd 
labels: 
app: etcd-member 
spec: 
containers: 
- name: etcd 
image: "quay.io/coreos/etcd:v3.2.16" 
ports: 
- containerPort: 2379 
name: client 
- containerPort: 2380 
name: peer 


env: 
- Name: CLUSTER_SIZE 
value: "3" 


- name: SET_NAME 
value: "etcd" 
volumeMounts: 
- name: data 
mountPath: /var/run/etcd 
command: 
- "/bin/sh" 
mh -GeCXn 
= | 
IP=$(hostname -i) 


PEERS="" 
for i in $(seq © $((${CLUSTER_SIZE} - 1))); do 
PEERS="${PEERS}${PEERS:+, }${SET_NAME}-${i}=http://${SET_NAME}- 
${i}.${SET_NAME} :2380" 
done 
# Start etcd,. If cluster is already initialized the ~--initial-*、 
options will be ignored. 
exec etcd --name ${HOSTNAME} 和 
--listen-peer-urls http://${IP}:2380 \ 
--listen-client-urls http://${IP}:2379,http://127.0.0.1:2379 \ 
--advertise-client-urls http://${HOSTNAME}.${SET_NAME}:2379 \ 
--initial-advertise-peer-urls http://${HOSTNAME}.${SET_NAME}:2380 \ 
--initial-cluster-token etcd-cluster-1 \ 
--initial-cluster ${PEERS} 和 
--initial-cluster-state new \ 
--data-dir /var/run/etcd/default.etcd 
volumeCclaimTemplates: 
- metadata: 
name: data 
spec: 
storageClassName: gluster-dynamic 
accessModes: 
- "ReadwriteOnce" 
resources: 
requests: 
storage: 16i 


首先 ， 将 上 述 资 源 定 义 创建 于 集群 中 。 当 依赖 的 镜像 文件 不 存在 
时 ， 下 载 镜像 的 过 程 会 导致 创建 时 长 略 长 ， 此 处 需要 耐心 等 待 


~]$ kubect1 apply -f etcd-statefulset.yaml 
statefulset.apps "etcd" created 


在 男 一 终端 ， 可 使 用 下 列 命 令 监 控 各 Pod 资 源 的 创建 过 程 ， 直 到 
它们 都 转 为 正常 的 运行 状态 为 止 : 


~]$ kubect1 get pods -1 app=etcd-member -w 


NAME READY STATUS RESTARTS AGE 
etcd-0 0/1 Pending 0 0S 
etcd-0 0/1 Pending 0 0S 
etcd-0 0/1 ContainerCreating 0 0S 
etcd-0 1/1 Running 0 11S 
etcd-1 0/1 Pending 0 0S 
etcd-1 0/1 Pending 0 0S 
etcd-1 0/1 ContainerCreating 0 0S 
etcd-1 1/1 Running 0 11S 
etcd-2 0/1 Pending 0 0S 
etcd-2 0/1 Pending 0 0S 
etcd-2 0/1 ContainerCreating 0 1S 
etcd-2 1/1 Running 0 15S 


而 后 ， 检 测 9.5.1 和 中 创建 的 Service 资 源 Retcd-SVC 和 etcd- 外 “ 
经 正常 关联 到 相关 的 Pod 资 各 源 。 下 面 的 命令 结果 表示 它们 都 已 经 
过 标 此 次 从 器 关联 到 了 由 Pod 资 源 源 生 成 的 Endpoints 资 源 之 上 ， J 
资源 是 由 StatefulSet 控 制 器 etcd 创 建 而 成 的 : 


~]$ kubectl1 get endpoints -1 app=etcd 


NAME ENDPOINTS AGE 
etcd 10.244.1.50:2380,10.244.2.50:2380,10.244.3.57:2380 + 3 more... 1m 
etcd-client 10.244.1.50:2379,10.244.2.50:2379,10.244.3.57:2379 1m 


对 比 由 etcd 控 制 莫 创建 的 Pod 资 源 的 相关 信息 可 知 ， 上 面 的 
Endpoints 中 的 IP 地 址 均 属于 由 etcd 控 制 创建 的 Pod 资 源 : 


~]$ kubectl1 get pods -1 app=etcd-member -0 wide 


NAME READY STATUS RESTARTS AGE IP NODE 

etcd-0 1/1 Running 0 1m 10.244.3.57 node03.ilinux.io 
etcd-1 1/1 Running 0 1m 10.244.1.50 node01.ilinux.io 
etcd-2 1/1 Running 0 1m 10.244.2.50 node02.ilinux.io 


使 用 etcd 的 客户 端 工具 etcdctl 检 测 集 群 的 健康 状态 : 


~]$ kubectl1 exec etcd-90 -- etcdctl1 cluster-health 

member 2e80f96756a54ca9 is healthy: got healthy result from http://etcd- 
0.etcd:2379 

member 7fd61f3f79d97779 is healthy: got healthy result from http://etcd- 
1.etcd:2379 

member b429c86e3cd4e077 is healthy: got healthy result from http://etcd- 
2.etcd:2379 

cluster is healthy 


至 此 ,一 个 由 三 节点 (Pod 资源) 0 
来 了 ， 客 户 端 可 从 各 工作 刷 点 的 30290 端 口 在 Kubernetes 集 群 外 部 进 
访问 ， 而 各 Pod 资 源 既 可 以 直接 癌 Service 资 源 etcd-client 的 名 称 或 
10.106.60.53 (GT 发 出 访问 请 求 ， 也 可 以 向 Headless Service 资 
源 的 名 称 etcd 进 行 请 求 。 


需要 注意 的 是 ， 前 面 的 配置 文件 中 提供 的 StatefulSet 资 源 配置 要 求 
进行 规模 变动 时 ， 需 要 手动 对 etcd 集 群 执行 命令 以 完成 和 点 的 添加 或 
删除 ， 而 且 缩 容 时 要 移 移 除 节 点 再 缩减 副本 数量 ， 扩 容 时 要 先 提 升 副 
本 数量 再 添加 节点 ， 因此 它 的 主要 目标 里 不 包含 应 用 规模 的 自由 变 


动 ， 但 对 于 应 用 升级 的 支持 完好 。 例 如 ， 将 镜像 文件 版 本 升级 至 
V3.2.17 的 版 本 : 


~]$ kubectl1 set image statefulset etcd etcd=quay.io/coreos/etcd:v3.2.17 
statefulset.apps "etcd" image updated 


而 后 使 用 “kubectl rollout status” 命 令 监 控 其 深 动 升级 过 程 中 的 状态 


变动 : 


~]$ kubectl1 rollout status statefulset etcd 

Waiting for 1 pods to be ready... 

Waiting for partitioned roll out to finish: 1 out of 3 new pods have been 
updated... 

Waiting for 1 pods to be ready... 

Waiting for partitioned roll out to finish: 2 out of 3 new pods have been 
updated... 

Waiting for 1 pods to be ready... 

partitioned roll out complete: 3 new pods have been updated... 


升级 完成 后 ， 可 于 相关 的 任 一 Pod 资 源 中 运行 etcdctl 命 令 查 看 应 用 
程序 的 版 本 是 否 已 经 升级 完成 : 


~]$ kubect1 exec etcd-0 -- etcdct1l -V 
etcdct1 version: 3.2.17 
API version: 2 


由 上 面 命 令 结 果 可 见 ， 应 用 程序 已 经 成 功 升级 至 3.2.17 的 版 本 。 深 
动 升级 过 程 中 ， 处 于 更 新 过 程 的 Pod 和 次 禹 源 对 象 无 法 正常 使 用 ， 不 过 ， 
客户 端 是 通 过 Service 质 源 提 供 的 入 口 而 非 Pod 资 源 本 身 的 标识 (如 名 
称 或 1P 地 址 ) 来 进行 访问 ， 因 此 并 不 会 出 现 服务 不 可 用 问题 。 


9.6 ”本 章 小 结 


本 章 着 重 讲解 了 有 状态 应 用 的 Pod 资 源 控制 器 StatefulSet， 有 状态 
应 用 相 较 于 无 状态 应 用 来 说 ， 在 管理 上 有 着 特有 的 复杂 之 处 ， 甚 至 不 
同 的 有 状态 应 用 的 管理 方式 各 不 相同 ， 在 部 署 时 需要 予以 精心 组 织 。 


:StatefulSet 依 赖 于 Headless Service 资 源 为 其 Pod 资 源 创建 DNS 资源 
记录 。 


.每 个 Pod 资 源 均 拥有 固定 且 唯 一 的 名 称 ， 并 且 需 要 由 DNS 服务 解 


.Pod 资 源 中 的 应 用 需要 依赖 于 PVC 和 PV 持 久保 存 其 状态 数据 。 
文 持 扩 容 和 缩 容 ， 但 具体 的 实现 机 制 依赖 于 应 用 本 喘 。 
` 文 持 目 动 更 新 ， 默 认 的 更 新 策略 为 深 动 更 新 机 制 。 


第 10 革 认证、 授权 与 准 入 控制 


在 任何 将 资源 或 服务 提供 给 有 限 使 用 者 的 系统 上 ， 认 证 和 授权 都 
是 两 个 必 不 可 少 的 功能 ， 认 证 用 于 身份 鉴别 ， 而 授权 则 实现 权限 分 
派 。Kubernetes 以 插件 化 的 方式 实现 了 这 两 种 功能 ， 且 分 别 存在 多 种 
可 用 的 插件 。 男 外 ， 它 还 支持 准 入 控制 机 制 ， 用 于 补充 授权 机 制 以 实 
现 更 精细 的 访问 控制 功能 。 本 章 主 要 讲解 Kubernetes 系 统 和 常用 的 认 
证 、 授 权 及 准 入 控制 机 制 。 


10.1 访问 控制 概述 


API Server 作 为 Kubernetes 集 群 系统 的 网 天 ， 是 访问 及 管理 资源 对 
象 的 唯一 入 口 ， 余 下 所 有 需要 访问 集群 资源 的 组 件 ， 包 括 kube- 
controller-manager、kube-scheduler、kubelet 和 kube-proxy 等 集群 基础 组 
件 、CoreDNS 等 集群 的 附加 组 件 以 及 此 前 使 用 的 kubectl 命 令 等 都 要 经 
由 此 网 关 进 行 集群 访问 和 管理 。 这 些 客 户 端 均 要 经 由 API Server 访 问 或 
改变 集群 状态 并 完成 数据 存储 ， 并 由 它 对 每 一 次 的 访问 请 求 进行 合法 
性 检验 ， 包 括 用 户 喘 份 鉴别 、 操 作 权 限 验 证 以 及 操作 是 否 符 合 全 局 规 
范 的 约束 等 。 所 有 检查 均 正常 完成 且 对 象 配 置信 息 合法 性 检验 无 误 之 
后 才能 访问 或 存 入 数据 于 后 并 存储 系统 etcd 中 ， 如 图 10-1 所 示 。 


客户 端 认 证 操作 由 API Server 配 置 的 一 到 多 个 认证 插件 完成 。 收 到 
请 求 后 ，API Server 依 次 调用 为 其 配置 的 认证 插件 来 认证 客户 端 刁 份 ， 
直到 其 中 一 个 插件 可 以 识别 出 请 求 者 的 吴 份 为 目 。 授 权 操作 由 一 到 多 
个 授权 插件 进行 ， 它 负责 确定 那些 通过 认证 的 用 户 是 否 有 权限 执行 其 
发 出 的 资源 操作 请 求 ， 如 创建 、 读 取 、 删 除 或 修改 指定 的 对 象 等 。 随 
后 ， 通 过 授权 检测 的 用 户 所 请 求 的 修改 相关 的 操作 还 要 经 由 一 到 多 个 
准 入 控制 插件 的 遍历 检测 ， 例 如 使 用 默认 值 补足 要 创建 的 目标 资源 对 
象 中 未 定义 的 各 字段 、 检 查 目 标 Namespace 资 源 对 象 是 否 存在 、 检 查 是 
和 限制 ， 等 等 ， 而 其 中 任何 的 检查 失败 都 可 能 会 导致 写 
入 操作 失败 。 
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10.1.1 用 户 账户 与 用 户 组 


Kubernetes 并 不 会 存储 由 认证 插件 从 客户 端 请 求 中 提取 出 的 用 户 
及 所 属 组 的 信息 ， 它 们 仅仅 用 于 检验 用 户 是 否 有 权限 执行 其 所 请 求 的 
操作 。 客 户 端 访问 API 服 务 的 途径 通常 有 二 种 : kubecd、 客 户 端 库 或 
者 直接 使 用 REST 接 口 进行 请 求 ， 而 可 以 执行 此 类 请 求 的 主体 也 被 
Kubernetes 分 为 两 类 : 现实 中 的 “人 ”和 Pod 对 和 象 ， 它 们 的 用 户 身 份 分 别 
对 应 于 常规 用 户 (User Account) 和 服务 账号 (Service Account) 。 


.User Account (用 户 账号 ) : 一 般 是 指 由 独立 于 Kubernetes 之 外 的 
其 他 服务 管理 的 用 户 账号 ， 例 如 由 管理 员 分 发 的 密 钥 、Keystone 一 类 
的 用 户 存 储 〈 账 号 库 ) 、 甚 至 是 包含 有 用 户 名 和 密码 列表 的 文件 等 。 
Kubernetes 中 不 存在 表示 此 类 用 户 账号 的 对 象 ， 因 此 不 能 被 直接 添加 
进 Kubernetes 系 统 中 。 


.Service Account (服务 账号 ) : 是 指 由 Kubernetes API 管 理 的 账 
号 ， 用 于 为 Pod 之 中 的 服务 进程 在 访问 Kubernetes API 时 提供 身份 标识 
(identity) 。 Service Account 通 常 要 绑 定 于 特定 的 名 称 空间 ， 它 们 由 
API Server 创 建 ， 或 者 通过 API 调 用 手动 创建 ， 附 带 着 一 组 存储 为 
Secret 的 用 于 访问 API Server 的 凭据 。 


User Account 通 常用 于 复杂 的 业务 逻辑 管控 ， 它 作用 于 系统 全 局 ， 
故 其 名 称 必 须 全 局 唯一 。 相 比较 来 说 ，Service Account 隶 属于 名 称 空 
上 间 ， 仪 用 于 实现 某 些 特定 的 操作 任务 ， 因 此 要 轻 量 得 多 。 这 两 类 账号 
都 可 以 隶属 于 一 个 或 多 个 用 户 组 。 用 户 组 只 是 用 户 账 号 的 逻辑 集合 ， 
它 本 身 并 没有 操作 权限 ， 但 附加 于 组 上 的 权限 可 由 其 内 部 的 所 有 用 户 
继承 ， 以 实现 高 效 的 授权 管理 机 制 。Kubernetes 有 着 以 下 几 个 内 建 的 
用 于 特殊 目的 的 组 。 


.System: unauthenticated: 未 能 通过 任何 一 个 授权 插件 检验 的 账 
号 ， 即 未 通过 认证 测试 的 用 户 所 属 的 组 。 


System: authenticated: 认证 成 功 后 的 用 户 目 动 加 入 的 一 个 组 ， 用 
于 快捷 引用 所 有 正常 通过 认证 的 用 户 账号 。 


.System: serviceaccounts: 当前 系统 上 的 所 有 Service Account 对 


oO 


.System: serviceaccounts: <namespace>: 特定 名 称 空间 内 所 有 的 
Service Account 对 象 。 


API 请 求 要 勾 与 普通 用 户 或 服务 账户 进行 绑 定 ， 要 么 被 视 为 匿名 
请 求 。 这 意味 着 群集 内 部 或 外 部 的 每 个 进程 ， 包 括 由 人 类 用 户 使 用 的 
kubectt， 到 节点 上 的 kubelet， 再 到 控制 平面 的 成 员 组 件 ， 必 须 在 同 API 
服务 器 发 出 请 求 时 进行 届 份 验证 ， 否 则 即 被 视 为 匿名 用 户 。 


10.1.2 认证、 授权 与 准 入 控制 基础 


API Server 处 理 请 求 的 过 程 中 ， 认 证 插件 负责 鉴定 用 户 身 份 ， 授 权 
插件 用 于 操作 权限 许可 鉴别 ， 而 准 入 控制 则 用 于 在 资源 对 象 的 创建 、 
删除 、 更 新 或 连接 (proxy) 操作 时 实现 更 精细 的 许可 检查 ， 其 相互 间 
的 作用 关系 如 图 10-1 所 示 。 


Kubernetes 使 用 二 份 验证 插件 对 API 请 求 进行 届 份 验证 ， 支 持 的 认 
证 方式 包括 客户 端 证 书 、 承 载 令 牌 (bearer tokens) 、 身 份 验 证 代理 
(authenticating proxy) 或 HTTP basic 认证 等 。API Server 接 收 到 访问 请 
求 时 ， 它 将 调用 认证 插件 尝试 将 以 下 属性 与 访问 请 求 相关 联 。 


-Username: 用 户 名 ， 如 kubernetes-admin 等 。 
UID: 用 户 的 数字 标签 符 ， 用 于 确保 用 户 身份 的 唯一 性 。 
.Groups: 用 户 所 属 的 组 ， 用 于 权限 指派 和 继承 。 

Extra: 键 值 数据 类 型 的 字符 串 ， 用 于 提供 认证 时 需要 用 到 的 额外 


日 / 己 ， 8 


API Server 支 持 同时 启用 多 种 认证 机 制 ， 但 至 少 应 该 分 别 为 Service 
Account 和 User Account 各 目 启 用 一 个 认证 插件 。 同 时 启用 多 种 认证 机 
制 时 ， 认 证 过 程 会 以 串 行 的 方式 进行 ， 直 到 一 种 认证 机 制 成 功 完成 即 
结束 。 知 认证 失败 ， 则 服务 器 会 啊 应 401 状 态 码 ， 反 之 ， 请 求 者 就 会 被 
识别 为 某 个 具体 的 用 户 〈 以 其 用 户 名 进行 标识 ) ， 并 且 随 后 的 操作 都 
将 以 此 用 户 身 份 来 进行 。 


具体 来 说 ，API Server 文 持 以 下 儿 种 具体 的 认证 方式 ， 其 中 所 有 的 
令 牌 认 证 机 制 通 间 被 统称 为 承载 令 牌 认证 。 


1) X509 客 户 端 证 书 认证 : 客户 端 在 请 求 报 文 中 携带 X509 格 式 的 
数字 证 书 用 于 认证 ， 认 证 通过 后 ， 证 书 中 的 主体 标识 (Subject) 将 被 
识别 为 用 户 标识 ， 其 中 的 CN (Common Name) 字段 是 用 户 名 ，O 

(Organization) 是 用 户 所 属 的 组 ， 


如 “/CN=ilinux/O=opmasters/O=admin” 中 ， 用 户 名 为 ilinux， 其 属于 
opmasters 和 admin 两 个 组 。 


2) 静态 令 牌 文件 (Static Token File) : 即 保存 着 令 牌 信息 的 文 
件 ， 由 kube-apiserver 的 命令 行 选 项 --token-auth-file 加 载 ， 且 服务 絮 启 
动 后 不 可 更 改 ; HTTP 客户 端 也 能 使 用 承载 令 牌 进行 号 份 验证 ， 将 令 牌 
进行 编码 后 ， 通 过 请 求 报 文中 的 Authorization 首 部 承载 传递 给 API 
Server 即 可 。 


3) 引导 令 牌 《Bootstrap Tokens) : 一 种 动态 管理 承载 令 牌 进行 身 
份 认 证 的 方式 ， 和 常用 于 人 简化 新 建 Kubernetes 集 群 的 万 点 认证 过 程 ， 需 
要 通过 --experimental-bootstrap-token-auth 选 项 局 用 ; 有 新 的 工作 节点 
首次 加 入 时 ，Master 使 用 引导 令 牌 确认 节点 里 份 的 合法 性 之 后 自动 为 
其 签署 数字 证 书 以 用 于 后 续 的 安全 通信 ， 使 用 kubeadm join 命 令 将 节点 
加 入 kubeadm 初 始 化 的 集群 时 使 用 的 即 是 这 种 认证 方式 ， 这些 令 牌 作 
为 Secrets 存 储 在 kube-system 命 名 空间 中 时 ， 可 以 动态 管理 和 创建 它 
们 ， 而 Controller Manager 包 含 一 个 TokenCleaner 控 制 器 ， 用 于 删除 过 期 
的 引导 令 牌 。 


4) 静态 密码 文件 : 用 户 名 和 密码 等 令 牌 以 明文 格式 存储 的 CSV 格 
式 文 件 ， 由 kube-apiserver 使 用 --basic-auth-file 选 项 进行 加 载 ; 客户 端 在 
HTTP basic 认 证 中 将 认证 用 户 的 用 户 名 和 密码 编码 后 以 承载 令 牌 的 格 
式 进行 认证 。 


5) 服务 账户 令 牌 : 由 kube-apiserver 上 自动 启用 ， 并 可 使 用 可 选 选项 
加 载 --service-account-key-file 验 证 承载 令 牌 的 密 铀 ， 省 略 时 将 使 用 
kube-apiserver 上 自己 的 证 书 匹配 的 私 钥 文 件 ，Service Account 通 常 由 API 
Server 目 动 创建 ， 并 通过 ServiceAccount 准 入 控制 絮 将 其 注入 Pod 对 
象 ， 包 括 Service Account 上 的 承载 令 脾 ， 容 絮 中 的 应 用 程序 请 求 API 
Server 的 服务 时 将 以 此 完成 喘 份 认 证 。 


6) OpenID 连 接 令 牌 : OAuth2 的 一 种 认证 风格 ， 由 Azure AD、 
Salesforce 和 Google 等 DAuth2 服 务 商 所 文 持 ， 协 议 的 主要 扩展 是 返回 的 
附加 字段 ， 其 中 的 访问 令 牌 也 称 为 ID 令 牌 ; 它 属 于 JSON Web 令 牌 

(JWT) 类 型 ， 有 着 服务 器 签名 过 的 常用 字段 ， 如 email 等 ，kube- 
apiserver 局 用 这 种 认证 功能 的 相关 选项 较 多 。 


7) Webhook 令 牌 ，HTTP 身 份 验 证 允许 将 服务 器 的 URL 注 册 为 
Webhook， 并 接收 带 有 承载 令 牌 的 POST 请 求 进行 身份 认证 ， 客 户 端 使 
用 kubeconfig 格 式 的 配置 文件 ， 在 文件 中 ，“users” 指 的 是 API 服 务 句 
Webhook, “clusters” 指 的 是 API Server 。 


8) 认证 代理 : API Server 支 持 从 请 求 首 部 的 值 中 识别 用 户 ， 如 X- 
Remote-User 首 部 ， 它 旨 在 与 身份 验证 代理 服务 相 结合 ， 并 由 该 代理 设 
置 相应 的 请 求 首部 。 


9) Keystone 密 码 : 借助 于 外 部 的 Keystone 服 务 器 进行 号 份 认证 。 


10) 匿名 请 求 : 未 被 任何 验证 机 制 明确 拒绝 的 用 户 即 为 匿名 用 
户 ， 其 会 被 自动 标识 为 用 户 名 system: anonymous， 并 隶属 于 systemi: 
unauthenticated 用 户 组 ， 在 API Server 启 用 了 除 AlwaysAllow 以 外 的 认证 
机 制 时 ， 匿 名 用 户 处 于 启用 状态 ， 不 过 ， 管 理 员 可 通过 --anonymous- 
auth=false 选 项 将 其 禁用 。 


另外 ，API Server 还 允许 用 户 通过 模拟 (impersonation) 首部 来 冒 
充 另 一 个 用 户 ， 这 些 请 求 可 以 以 手动 的 方式 覆盖 请 求 中 用 于 身份 验证 
的 用 户 信息 。 例 如 ， 管 理 员 可 以 使 用 此 功能 临时 模拟 其 他 用 户 来 查看 
请 求 是 否 被 拒绝 进行 授权 策略 调试 。 


API Server 是 一 种 REST API， 除 了 身份 认证 信息 之 外 ， 一 个 请 求 
报 文 还 需要 提供 操作 方法 及 其 目标 对 象 ， 如 针对 某 Pod 资 源 对 象 进行 
的 创建 、 查看 、 修 改 或 删除 操作 等 ， 具 体 来 说 ， 请 求 报 文 包含 如 下 信 


.API: 用 于 定义 请 求 的 目标 是 否 为 一 个 API 资 源 。 
"Request path: 请 求 的 非 资源 型 路 径 ， 如 /api 或 /healthz。 


.API group: 要 访问 的 API 组 ， 仅 对 资源 型 请 求 有 效 ; 默认 为 “core 
API group”。 


.Namespace: 目标 资源 所 属 的 名 称 空 间 ， 仅 对 隶属 于 名 称 空 间 类 
型 的 资源 有 效 。 


.API request verb: API 请 求 类 的 操作 ， 即 资源 型 请 求 (对 资源 执 
行 的 操作 ) ， 包 括 get 、list、create 、update 、patch 、watch 、proxy 、 
redirect、delete 和 deletecollection 等 。 


:HTTP request verb: _ HTTP 请求 类 的 操作 ， 即 非 资 源 型 请 求 要 执行 
的 操作 ， 如 get、post、put 和 delete 。 


.Resource: 请 求 的 目标 资源 的 ID 或 名 称 。 

.Subresource: 请 求 的 子 资 源 。 

为 了 核验 用 户 的 操作 许可 ， 成 功 通过 身份 认证 后 的 操作 请 求 还 需 
要 转交 给 授权 插件 进行 许可 权限 检查 ， 以 确保 其 拥有 执行 相应 的 操作 
" i, 。API Server 主 要 支持 使 用 四 类 内 建 的 授权 插件 来 定义 用 户 的 操 


.Node: 基于 Pod 资 源 的 目标 调度 节点 来 实现 的 对 kubelet 的 访问 控 
制 。 


:ABAC: attribute-based access control， 基 于 属性 的 访问 控制 。 


:RBAC: role-based access control， 基 于 角色 的 访问 控制 。 


`Webhook: 基于 HTTP 回 调 机 制 通过 外 部 REST 服 务 检查 确认 用 户 
授权 的 访问 控制 。 


另外 ， 还 有 AlwaysDeny 和 AlwaysAllow 两 个 特殊 的 授权 插件 ， 其 
中 AlwaysDeny 〈 总 是 拒绝 ) 仅 用 于 测试 ， 而 AlwaysAllow 〈 总 是 允 
许 ) 则 用 于 不 期 望 进行 授权 检查 时 直接 于 授权 检查 阶段 放行 的 所 有 操 
作 请 求 。 启 动 API Server 时 ，“--authorization-mode” 选 项 用 于 定义 要 局 
用 的 授权 机 制 ， 多 个 选项 彼此 之 间 以 逗号 分 隔 。 


而 准 入 控制 器 (Admission Controller) 则 用 于 在 客户 端 请 求 经 过 
身份 验证 和 授权 检查 之 后 ， 但 在 对 象 持久 化 存储 etcd 之 前 拦截 请 求 ， 
用 于 实现 在 资源 的 创建 、 更 新 和 删除 操作 期 间 强 制 执 行 对 象 的 语义 验 
证 等 功能 ， 读 取 资 源 信息 的 操作 请 求 不 会 经 由 准 入 控制 器 的 检查 。 
API Server 内 置 了 许多 准 入 控制 器 ， 常 用 的 包含 如 下 几 和 种。 不过， 其 中 
的 个 别 控制 器 仪 在 较 新 版 本 的 Kubernetes 中 才 受 支持 。 


1) AlwaysAdmit: 允许 所 有 请 求 。 
2) AlwaysDeny: 拒绝 所 有 请 求 ， 仅 应 该 用 于 测试 。 


3) AlwaysPullImages: 总 是 下 载 镜像 ， 即 每 次 创建 Pod 对 象 之 前 
都 要 去 下 载 镜像 ， 常 用 于 多 租户 环境 中 以 确保 私有 镜像 仅 能 够 被 拥有 
权限 的 用 户 使 用 。 


4) NamespaceLifecycle: 拒绝 于 不 存在 的 名 称 空间 中 创建 资源 ， 
而 删除 名 称 空间 将 会 级 联 删 除 其 下 的 所 有 其 他 资源 。 


5) LimitRanger: 可 用 资源 范围 界定 ， 用 于 监控 对 设置 了 
LimitRange 的 对 象 所 发 出 的 所 有 请 求 ， 以 确保 其 资源 请 求 不 会 超 限 。 


6) ServiceAccount: 用 于 实现 Service Account 管 控 机 制 的 自动 化 ， 
实现 创建 Pod 对 象 时 自动 为 其 附加 相关 的 Service Account 对 象 。 


7) PersistentVolumeLabel: 为 那些 由 云 计算 服务 商 提 供 的 PV 自动 
附加 region 或 zone 标签 ， 以 确保 这 些 存储 卷 能 够 正确 关联 且 仅 能 关联 到 
所 属 的 region 或 Zone。 


8) DefaultStorageClass: 监控 所 有 创建 PVC 对 象 的 请 求 ， 以 保证 
那些 没有 附加 任何 专用 StorageClass 的 请 求 会 目 动 设 定 一 个 默认 值 。 


9) ResourceQuota: 用 于 对 名 称 空 间 设置 可 用 资源 的 上 限 ， 并 确 
资源 限额 的 对 象 都 不 会 超出 名 称 空 x 间 的 资 
源 


10) DefaultTolerationSeconds: 如 果 Pod 对 象 上 不 存在 污点 宽容 期 
限 ， 则 为 它们 设置 默认 的 宽容 期 ， 以 视 容 : ‘notready: 
NoExecute” 和 “unreachable: NoExctute” 类 的 污点 5 分 钟 时 间 。 


11) ValidatingAdmissionWebhook: 并 行 调用 匹配 当前 请 求 的 所 有 
验证 类 的 Webhook， 任 何 一 个 校 验 失 败 ， 请 求 即 失败 。 


12) MutatingAdmissionWebhook: 串 行 调用 匹配 当前 请 求 的 所 有 
变异 类 的 Webhook， 每 个 调用 都 可 能 会 更 改 对 象 。 


早期 的 准 入 控制 器 代码 需要 由 管理 员 编 译 进 kube-apiserver 中 才能 
使 用 ， 其 实现 方式 缺乏 灵活 性 。 于 是 ，Kubernetes 目 1.7 有 版 本 引入 了 
Initializers 和 External Admission Webhooks 来 党 试 突破 此 限制 ， 而 且 目 
1.9 版 本 起 ，External Admission Webhooks 被 分 为 MutatingAdmission- 
Webhook 和 ValidatingAdmissionWebhook 两 种 类 型 ， 分 别 用 于 在 API 中 
执行 对 象 配置 的 变异 和 验证 操作 。 检 查 期 间 ， 只 有 那些 顺利 通过 所 有 
准 入 控制 器 检查 的 资源 操作 请 求 的 结果 才能 保存 到 etcd 中 ， 实 现 持久 
存储 ， 换 人 句 话 讲 ， 任 何 一 个 准 入 控制 絮 的 拒绝 都 将 导致 请 求 失败 。 


10.2 ”服务 账户 管理 与 应 用 


运行 过 程 中 ，Pod 资 源 里 的 容器 进程 在 某 些 场景 中 需要 调用 
Kubemetes API 或 者 其 他 类 型 的 服务 ， 而 这 些 服务 通常 需要 认证 客户 端 
身份 ， 如 调度 器 、Pod 控 制 器 或 节点 控制 器 ， 甚 至 是 获取 启动 容器 的 
镜像 访问 的 私有 Registry 服 务 等 。 服 务 账 户 就 是 用 于 让 Pod 对 象 内 的 容 
器 进程 访问 其 他 服务 时 提供 身份 认证 信息 的 账户 。 一 个 Service 
Account 资 源 一 般 由 用 户 名 及 相关 的 Secret 对 象 组 成 。 


10.2.1 ”Service Account 目 动 化 


细心 的 读者 或 许 已 经 注意 到 ， 此 前 创建 的 每 个 Pod 资 源 都 目 动 天 
联 了 一 个 存储 卷 ， 并 由 其 容 右 挂 载 
至 /varrun/secrets/kubernetes.io/serviceaccount 目 未 ， 例 如 ， 下 面 
由 “kubectl describe pod” 命 令 显示 的 某 Pod 对 象 朱 述 信息 的 族 断 : 


Containers: 
Mounts: 
/var/run/secrets/kubernetes.io/serviceaccount from default-token-bq6zc (ro) 


Volumes: 


default-token-bq6zc: 
Type: Secret (a volume populated by a Secret) 
SecretName: default-token-bq6zc 
Optional: false 


挂 载 点 目录 中 通常 存在 三 个 文件 ，ca.crt、namespace 和 token， 其 
中 ，token 文 件 保存 了 Service Account 的 认证 token， 容 器 中 的 进程 使 用 
它 癌 API Server 发 起 连接 请 求 ， 进 而 由 认证 插件 完成 用 户 认 证 并 将 其 用 
户 名 传递 给 授权 插件 。 


每 个 Pod 对 和 象 都 只 有 一 个 服务 账户 ， 铬 创建 Pod 资 源 时 未 予以 明确 
指定 ， 则 和 名 为 ServiceAccount 的 准 入 控制 器 会 为 其 自动 附加 当前 名 称 空 
间 中 默认 的 服务 账户 ， 其 名 称 通常 为 default。 下 面 的 命令 显示 了 
default 这 个 服务 账户 的 详细 信息 : 


~]$ kubectl1 describe serviceaccount default 


Name : default 
Mountable Secrets : default-token-bq6zc 
Tokens: default-token-bq6zc 
Events: <none> 


Kubernetes 系 统 通过 三 个 独立 的 组 件 间 的 相互 协作 来 实现 服务 账 
户 的 目 动 化 ， 三 个 组 件 具体 为 : Service Account 准 入 控制 器 、 令 牌 控 
制 器 (token controller) 和 Service Account 账 户 控制 器 。Service 
Account 控 制 需 负 责 为 名 称 空 间 管理 相应 的 资源 ， 并 确保 每 个 名 称 空 间 


中 都 存在 一 个 名 为 “default" 的 Service Account 对 象 。Service Account 准 
入 控制 如 是 API Server 的 一 部 分 ， 负 责 在 创建 或 更 新 Pod 时 对 其 按 需 进 
行 Service Account 对 象 相关 信息 的 修改 ， 这 包括 如 下 操作 。 


. 若 Pod 没 有 明确 定义 使 用 的 ServiceAccount 对 象 ， 则 将 其 设置 
为 “default”。 


-确保 Pod 明 确 引 用 的 ServiceAccount 已 存在 ， 否 则 请 求 将 被 拒绝 。 


: 若 Pod 对 象 中 不 包含 ImagePullSecerts， 则 把 Service Account 的 
ImagePullSecrets 添 加 于 其 上 。 


-为 市 有 访问 API 的 令 牌 的 Pod 添 加 一 个 存储 卷 。 


:为 Pod 对 象 中 的 每 个 容 絮 添加 一 个 volumeMounts， 挂 载 
至 /var/run/secrets/kubernetes.io/serviceaccount 。 


令 牌 控制 锅 是 controller-manager 的 子 组 件 ， 工 作 于 异步 模式 。 其 
负责 完成 的 任务 具体 如 下 。 


:监控 Service Account 的 创建 操作 ， 并 为 其 添加 用 于 访问 API 的 
Secret 对 象 。 


监控 Service Account 的 删除 操作 ， 并 删除 其 相关 的 所 有 Service 


Account 令 牌 密 钥 。 


:监控 Secret 对 象 的 添加 操作 ， 确 保 其 引用 的 Service Account 已 存 
在 ， 并 在 必要 时 为 Secret 对 象 添 加 认证 令 牌 。 


:监控 Secret 对 象 的 删除 操作 ， 以 确保 删除 每 个 Service Account 中 对 
此 Secret 的 引用 。 


需要 注意 的 是 ， 为 确保 完整 性 等 ， 必 须 为 kube-controller-manager 
使 用 “--service-account-private-key-file” 选 项 指定 一 个 私 钥 文 件 ， 以 用 于 
对 生成 的 服务 账户 令 牌 进行 签名 ， 此 私 钥 文 件 必须 是 pem 格 式 。 类 似 
地 ， 还 要 为 kube-apiserver 使 用 “--service-account-key-file” 指 定 与 前 面 的 
私 钥 配对 儿 的 公 钥 文件 ， 以 用 于 在 认证 期 间 对 认证 令 牌 进行 校 验 。 


10.2.2 ”创建 服务 账户 


Service Account 是 Kubernetes API 上 的 一 种 资源 类 型 ， 它 隶属 于 名 
外 空间 ， 用 于 让 Pod 对 和 象 内 部 的 应 用 程序 在 与 API Server 通 信 时 完成 号 
份 认证 。 事 实 上 ， 每 个 名 称 空 间 都 有 一 个 名 为 default 的 默认 资源 对 
象 ， 如 下 面 的 命令 及 其 结果 所 示 ， 其 可 用 于 让 Pod 对 象 有 权限 读 取 同 
一 名 称 空间 中 的 其 他 资源 对 象 的 元 数据 信息 。 需 要 赋予 Pod 对 象 更 多 
操作 权限 时 ， 则 应 该 由 用 户 按 需 创建 目 定义 的 Service Account 资 源 : 


~]$ kubect1 get serviceaccounts --all-namespaces 
NAMESPACE NAME SECRETS AGE 


default default 1 
kube-public default 1 2h 
kube-system default 1 2h 


每 个 Pod 对 象 均 可 附加 其 所 属 名 称 空间 中 有 的 一 个 Service Account 资 
源 ， 旦 只 能 附加 一 个 。 不 过 ， 一 个 Service Account 资 源 可 由 其 所 属 名 
尔 空 间 中 的 多 个 Pod 对 象 共 至 使 用 。 创 建 Pod 资 源 时 ， 用 户 可 使 
用 “spec.serviceAccountName” 属 性 直接 指定 要 使 用 的 Service Account 对 
象 ， 或 者 省 略 此 字段 而 由 其 自动 附加 当前 名 称 空间 中 默认 的 Service 


Account (default) 


可 使 用 资源 配置 文件 创建 Service Account 资 源 ， 也 可 直接 使 
用 “kubectl create servic-eaccount” 命 令 进 行 创建 ， 提 供认 证 令 牌 的 Secret 
对 象 会 由 命令 目 动 创 建 完 成 。 下 面 的 配置 清单 是 一 个 ServiceAccount 资 
源 示例 ， 它 仅 指 定 了 创建 名 为 sa-demo 的 服务 账户 ， 其 余 的 信息 则 交 由 
系统 自动 生成 : 


apiVersion: v1 
kind: ServiceAccount 
metadata: 
name: sa-demo 
namespace: default 


创建 Pod 对 象 时 ， 可 为 Pod 对 象 指定 使 用 目 定 义 的 服务 账户 ， 从 而 
实现 自主 控制 Pod 对 象 资源 的 访问 权限 。Pod| 可 API Server 发 出 请 求 
上 时， 其 携带 的 认证 令 牌 在 通过 认证 后 将 由 授权 插件 来 判定 相关 的 


Service Account 是 否 有 权限 访问 其 所 请 求 的 资源 。Kubernetes 支 持 多 种 
0 由 管理 员 负 责 选 定 及 配置 ，RBAC 是 目前 较为 主流 的 选 
后 O 


10.2.3 ”调用 imagePullSecret 资 源 对 象 


ServiceAccount 资 源 还 可 以 基于 spec.imagePullSecret 字 段 附 带 一 个 
由 下 载 镜像 专用 的 Secret 资 源 组 成 的 列表 ， 用 于 在 进行 容器 创建 时 ， 从 
某 私有 镜像 仓库 下 载 镜 像 文件 之 前 进行 服务 认证 。 下 面 的 示例 定义 了 
一 个 有 着 从 本 地 私有 镜像 仓库 harbor 中 下 载 镜 像 文 件 时 用 于 认证 的 
Secret 对 和 象 信息 的 ServiceAccount: 


apiVersion: v1 
kind: ServiceAccount 
metadata: 

name: image-download-sa 
imagePullSecrets: 
- name: local-harbor-secret 


其 中 ，l]ocal-harbor-secret 是 docker-registry 类 型 的 Secret 对 象 ， 由 用 
户 提 前 手动 创建 ， 它 可 以 通过 键 值 数据 提供 docker 仓 库 服 务 器 的 地 
址 、 授 入 服务 名 的 用 户 名 、 密 码 及 用 户 的 电子 邮件 等 信息 。 认 证 通过 
后 ， 引 用 了 此 ServiceAccount 的 Pod 资 源 即 可 从 指定 的 镜像 仓库 中 下 载 
由 image 字 段 指 定 的 镜像 文件 。 


10.3”X.509 数 字 证 书 认证 


Kubernetes 支 持 的 HTTPS 客 户 问 证 书 认 证 、token 认 证 及 HTTP basic 
认证 几 种 认证 方式 中 ， 基 于 SSL/ATLS 协 议 的 客户 端 证 书 认 证 以 其 安全 性 
高 且 易 于 实现 等 特性 ， 而 成 为 主要 使 用 的 认证 方式 之 一 。 


SSL/TLS 最 常见 的 使 用 场景 是 将 X.509 证 书 与 服务 器 端 相 关联 ， 但 
不 为 客户 端 使 用 证 书 。 这 意味 着 客户 端 可 以 验证 服务 端的 身份 ， 但 服 
务 端 无 法 验证 客户 端的 身份 (至 少 不 能 通过 SSL/TLS 协 议 进 行 ) 。 这 很 
容易 理解 ， 毕 竞 SSL/TLS 安 全 性 最 初 是 为 互联 网 应 用 开发 ， 保 护 客户 站 
反而 是 高 优先 级 的 需求 ， 例 如 ， 在 需要 连接 到 银行 的 网 站 时 需要 确保 
该 网 站 是 真实 的 等 ， 如 图 10-2 所 示 。 


此 外 ， 验 证 客户 端 时 ， 使 用 其 他 机 制 (如 HTTP 基 本 认证 ) 通常 会 
更 容易 些 ， 而 且 这 些 机 制 不 会 产生 生成 和 分 发 X.509 证 书 的 高 昂 维护 开 
销 。 不 过 ， 安 全 性 要 求 较 高 的 场景 中 ， 使 用 组 织 私 有 的 证 书 分 发 系统 
也 一 样 能 够 使 用 数字 证 书 进行 客 己 并 认 证 。 图 10-3 展 示 了 服务 站 与 客户 
端的 双向 认证 机 制 。 


服务 端 与 客户 端 互相 认证 的 场景 中 ， 双 方 各 上 自 需 要 配备 一 套 证 
书 ， 并 拥有 信任 的 签证 机 构 的 证 书 列表 。 使 用 私有 签证 机 构 颁发 的 数 
字 证 书 时 ， 用 户 通 常 需 要 手动 将 此 私有 签证 机 构 的 证 书 添加 到 信任 的 
签证 机 构 列 表 中 。 
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图 10-2 ”SSL/TLS 服务 端 认证 (图 片 来 源 : Red Hat Inc.) 
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图 10-3 ”SSL/TLS 双向 认证 (图 片 来 源 : Red Hat Inc.) 


10.3.1 Kubernetes 中 的 SSL/TLS 认 证 


构建 安全 基础 通信 环境 的 Kubernetes 集 群 时 ， 需 要 用 到 TLS 及 数字 
证 书 的 通信 场景 有 很 多 种 ， 如 图 10-4 所 示 。API Server 是 整个 Kubernetes 
集群 的 通信 网 天 ，controller-manager 、scheduler 、kubelet 及 kube-proxy 
等 均 需 要 经 由 API Server 与 etcd 通 信 完 成 资源 状态 信息 的 获取 及 更 新 
等 。 同 样 出 于 安全 通信 的 目的 ，master 的 各 组 件 (API Server、 
controller-manager 和 scheduler) 需要 基于 SSL/TLS 辣 外 提供 服务 ， 而 且 
与 集群 内 部 组 件 间 进行 通信 时 (主要 是 各 节点 上 的 kubelet 和 kube- 
proxy) 还 需要 进行 双向 身份 验证 。 


一 一 client 
\ 
/ 


图 10-4 ”Kubernetes 的 SSL/TLS 通 信 


Kubernetes 集 群 中 各 资源 的 状态 信息 ， 包 括 Secret 对 象 中 的 敏感 信 
息 等 均 以 明文 方式 存储 于 etcd 中 ， 因 此 ，etcd 集 群 内 各 广 点 则 的 通信 ， 
以 及 各 节点 与 其 客户 端 (主要 是 API sevrver) 之 间 的 通信 都 应 该 以 加 密 
的 方式 进行 ， 并 需 进 行 身 份 验证 。 


1) etcd 集 群 内 对 等 节点 通信 :，etcd 集 群 内 各 节点 间 的 集群 事务 通 
信 ， 默 认 监 听 于 TCP 的 2380 端 口 ， 基 于 SSL/TLS 通 信 时 需要 peer 类 型 的 
数字 证 书 ， 可 实现 节点 间 的 身份 认证 及 通信 安全 ， 这 些 证 书 需要 由 一 
个 专用 CA 进行 管理 。 


2) etcd 服 务 器 与 客户 端 通信 :，etcd 的 REST API 服 务 ， 默 认 监 听 于 
TCP 的 2379 端 口 ， 用 于 接收 并 啊 应 客户 闪 请 求 ， 基 于 SSL/TLS 通 信 ， 文 
持 服 务 端 认 证 和 双向 认证 ， 而 且 要 使 用 一 个 专用 CA 来 管理 此 类 证 书 ; 
kube-apiserver 束 是 etcd 服 务 的 主要 客户 端 。 


API Server 与 其 客户 端 之 间 采 用 HTTPS 通 信 可 兼顾 实现 通信 与 认证 
的 功能 ， 它 们 之 间 通 信 的 证 书 可 由 同一 个 CA 进行 管理 ， 其 客户 端 大 体 
可 以 分 为 如 下 三 类 * 


:控制 平面 的 kube-scheduler 和 kube-controller-manager 。 

:工作 太 点 组 件 kubelet 和 kube-proxy: 初次 接 入 集群 时 ，kubelet 可 目 
动 生 成 私 铀 和 证 书签 晋 请 求 ， 并 由 Master 力 其 目 动 进行 证 书签 名 和 和 颁 
发 ， 这 束 是 所 谓 的 tls bootstraping 。 

kubelet 及 其 他 形式 的 客户 器， 如 Pod 对 象 等 。 

集群 上 运行 的 应 用 (Pod) 同 其 客户 端的 通信 经 由 不 可 信 的 网 络 传 


输 时 也 可 能 需要 用 到 TLS/SSL 协 议 ， 如 Nginx Pod 与 其 客户 端 间 的 通 
. 客户 端 来 自 于 互联 网 时 ， 此 处 通常 需要 配置 一 个 公信 的 服务 端 证 


10.3.2 ”客户 端 配置 文件 kubeconfig 


包括 kubect、kubelet 和 kube-controller-manager 等 在 内 的 API Server 
的 各 类 客户 端 都 可 以 使 用 kubeconfig 配 置 文件 提供 接 入 多 个 集群 的 相关 
配置 信息 ， 包 括 各 API Server 的 UREL 及 认证 信息 等 ， 而 且 能 够 设置 成 不 
同 的 上 下 文 环境 ， 并 在 各 环境 之 间 快 速 切换 ， 如 图 10-5 所 示 。 


kubernetes clusterl 
API Server 


] /| 
kubectl kubeconfig -一 
L 4 


| kubernetes cluster2 
API Server 


图 10-5 kubectl 和 kubeconf ig 


使 用 kubeadm 初 始 集 群 后 生成 的 /etc/kubernetes/admin.conf 文 件 即 为 
kubeconfig 格 式 的 配置 文件 ， 其 由 kubeadm init 命 令 目 动 生成 ， 可 由 
kubectl 加 载 (默认 路 径 为 $4HOME/.kube/config) 后 用 于 接 入 服务 
贸 。*kubectl config view” 命 令 能 够 显示 当前 正在 使 用 的 配置 文件 ， 下 面 
的 命令 结果 打印 了 文件 中 配置 的 集群 列表 、 用 户 列 表 、 上 下 文 列 表 以 
及 当前 使 用 的 上 下 文 (current-context) 等 : 


[root@master ~]# kubectl1 config view 
apiVersion: v1 
clusters: 
- Cluster: 
certificate-authority-data: REDACTED 
server: https://172.16.0.70:6443 
name: kubernetes 
contexts: 
- context: 
cluster: kubernetes 
user: kubernetes-admin 
name: kubernetes-admin@kubernetes 
current-context: kubernetes-admin@kubernetes 
kind: Config 
preferences: {} 
Users: 
- name: kubernetes-admin 
USer : 


client-certificate-data: REDACTED 
client-key-data: REDACTED 


事实 上 ， 任 何 类 型 的 API Server 客 户 端 都 可 以 使 用 kubeconfig 进 行 
配置 ， 例 如 KubernetesNode 之 上 的 kubelet 和 kube-proxy 也 需要 将 其 用 到 
的 认证 信息 保存 于 专用 的 kubeconfig 文 件 中 ， 并 通过 --kubeconfig 选 项 进 
行 加 载 。 kubeconfig 文 件 的 定义 中 包含 以 下 几 项 主要 的 配置 ， 它 们 彼此 
之 间 的 关系 表示 也 由 图 10-6 给 出 了 。 


:clusters: 集群 列表 ， 包 含 访 问 API Server 的 URL 和 所 属 集群 的 名 称 


下 


-users: 用 户 列表 ， 包 含 访问 API Server 时 的 用 户 名 和 认证 信息 。 


contexts: kubelet 的 可 用 上 下 文 列 表 ， 由 用 户 列 表 中 的 某 特定 用 户 
名 称 和 集群 列表 中 的 茶 特 定 集群 名 称 组 合 而 成 。 


:current-context: kubelet 当 前 使 用 的 上 下 文 名 称 ， 即 上 下 文 列 表 中 
的 某 个 特定 项 。 


kubeconfig 
Users: 
- userl 
- User2 


clusters: 
- Clustersl 


- clusters2 
Clusterl 


contexts: 
- contextl | 
userl / 
/ 
clusterl 
| 
| 

Cluster2 


上 name: userl@ 


kubectl 
\ clusterl A 
| 


| - context2 
| user2 

| cluster2 
| name: user2(@ | 


| cluster2 


晶 current-context: 
contextl 


图 10-6 ”kubeconfig 文 件 格式 示意 图 


用 户 也 可 以 按 需 目 定义 相关 的 配置 信息 于 kubeconfig 配 置 文件 中 ， 
以 实现 使 用 不 同 的 用 户 账户 接 入 集群 等 功能 。kubeconfig 是 一 个 文本 文 
件 ， 虽 然 文 持 使 用 文本 处 理工 具 直接 进行 编辑 ， 但 这 里 建议 用 户 使 
用 “kubectl config” 命 令 进 行 设 定 ， 它 能 够 目 动 进行 语法 检测 等 额外 功 
能 。kubectl config 命 令 的 常用 操作 包含 如 下 几 项 。 
kubectl config view: 打印 kubeconfig 文 件 内 容 。 
kubectl config set-cluster: 设置 kubeconfig 的 clusters 配 置 段 。 


kubectl config set-credentials: 设置 kubeconfig 的 users 配 置 段 。 


kubectl config set-context: 设置 kubeconfig 的 contexts 配 置 段 。 


kubectl config use-context: 设置 kubeconfig 的 current-context 配 置 
段 o 


使 用 kubeadm 部 署 的 Kubernetes 集 群 默认 提供 了 拥有 集群 管理 权限 
的 kubeconfig 配 置 文件 /etc/kubernetes/admin.conf， 它 可 被 复制 到 任何 有 
着 kubectl 的 主机 上 以 用 于 管理 整个 集群 。 除 此 之 外 ， 管 理 员 还 可 以 创 
建 其 他 基于 SSL/TLS 认 证 的 自 定义 用 户 账号 ， 以 授予 非 管 理 员 级 的 集群 
资源 使 用 权限 ， 其 配置 过 程 由 两 部 分 组 成 : 一 是 为 用 户 创 建 专用 私 钥 
及 证 书 文件 ， 二 是 将 其 配置 于 某 kubeconfig 文 件 中 。 下 面 给 出 其 具体 的 
0 ， 并 借 此 创建 将 一 个 测试 用 户 kube-user1 用 于 后 文中 的 授权 测 
试 。 


第 一 步 ， 为 目标 用 户 账 号 kube-user1 创 建 私 钥 及 证 书 文件 ， 保 存 
于 /etc/kubernetes/pki 目 录 中 。 


全 二 二。 大同 中 的 操作 需要 在 Mastea 节 点 上 Dhioot 用 户 的 
份 执行 。 


1) 生成 私 钥 文件 ， 注 意 其 权限 应 该 为 600 以 阻止 其 他 用 户 随意 获 
取 ， 这 里 在 MasterT 点 上 以 root 用 户 进 行 操 作 ， 并 将 文件 放置 
于 /etc/kubernetes/pki 专 用 目录 中 : 


~]# cd /etc/kubernetes/pki 
~]# (umask 077; openssl genrsa -out kube-user1.key 2048) 


2) 创建 证 书签 署 请 求 ，-subj 选 项 中 CN 的 值 将 被 kubeconfig 作 为 用 
户 名 使 用 ，O 的 值 将 被 识别 为 用 户 组 : 


~]# openssl req -new -key kube-user1,key -out kube-user1.csr -subj "/CN=kube- 
user1 
0=kubeusers" 


3) 基于 kubeadm 安 装 Kubernetes 集 群 时 生成 的 CA 签署 证 书 ， 这 里 
设置 其 有 效 时 长 为 3650 天 : 


~]# openssl] x509 -req -in kube-useri.csr -CA ca.crt -CAkey ca.key \\ 
-CAcreateserial -out kube-useri1.crt -days 3650 


4) 验证 证 书信 息 (可 选 ) : 


~]# openssl] x509 -in kube-useri.crt -text -noout 


第 二 步 ， 以 默认 的 管理 员 kubernetes-admin@kubernetes 为 新 建 的 
kube-userl 设 定 kube-config 配 置 文件 。 配 置 结果 将 默认 保存 于 当前 系统 
用 户 的 .kube/config 文 件 中 ， 当 然 世 可 以 为 kubect 使 用 --kubeconfig 选 项 
指定 目 定 义 的 专用 文件 路 径 。 


1) 配置 集群 信息 ， 包 括 集群 名 称 、API Server URL 和 CA 证 书 ， 若 
集群 信息 已 然 存 在 ， 则 可 省 略 此 步 ， 另 外 ， 提 供 的 新 配置 不 能 与 现 有 
配置 中 的 集群 名 称 相同 ， 否 则 将 覆盖 它们 : 


~]$ kubect1l1 config set-cluster kubernetes --embed-certs=true \ 
--certificate-authority=/etc/kubernetes/pki/ca.crt --server="https://172.16. 
0.70:6443" 


2) 配置 客户 端 证 书 及 密 铀 ， 用 户 名 信息 会 通过 命令 从 证 书 Subject 
的 CN 值 中 目 动 担 取 ， 例 如 前 面 创 建 csr 时 使 用 的 “CN=kube-user1”， 而 组 
名 则 来 自 于 “O=kubeusers” 的 定义 : 


~]$ kubect] config set-credentials kube-user1 --embed-certs=true \ 
--Client-certificate=/etc/kubernetes/pki/kube-useri1.crt \ 
--Client-key=/etc/kubernetes/pki/kube-user1.key 


3) 配置 context， 用 来 组 合 cluster 和 credentials， 即 访问 的 集群 的 上 
下 文 。 如 果 为 管理 多 个 集群 而 设置 了 多 个 环境 ， 则 可 以 使 用 use-context 
来 进行 切换 : 


~]$ kubect] config set-context kube-useri@kubernetes --cluster=kubernetes --user= 
kube-user1 


4) 最 后 指定 要 使 用 的 上 下 文 ， 切 换 为 以 kube-user1 访 问 集 群 : 


~]$ kubect] config use-context kube-useri@kubernetes 


5) 测试 访问 集群 贷 源 ， 不 过 在 启用 RBAC 的 集群 上 执行 命令 时 ， 
kube-user1l 并 未 获得 集群 资源 的 访问 权限 ， 因 此 会 出 现 销 误 提 示 : 


~]$ kubectl get pods 
Error from server (Forbidden): pods is forbidden: User "kube-user1" cannot list 
pods 

in the namespace "default" 


此 时 ， 若 需 切换 至 管理 员 账 号 ， 则 可 使 用 “kubectl config use- 
context kubernetes-admin(@kubernetes” 命 令 来 完成 。 男 外 ， 临 时 使 用 某 
contextH ， 不 必 设 置 current-context， 只 需要 为 kubectl 命 令 使 用 --context 
选项 指定 目标 context 的 名 称 即 可 ， 如 “kubectl--context= kube- 
userl@Kkubernetes get pods”。 


10.3.3 ”TLS bootstrapping 机 制 


源 的 工作 列 点 接 入 集群 时 需要 事 移 配置 好 相关 的 证 书 和 私 钥 等 以 
进行 安全 通信 ， 管 理 员 既 可 以 手动 提供 相关 的 配置 ， 也 可 以 选择 由 
kubelet 目 行 生 成 私 铀 和 目 签 证 书 。 集 群 略 具 规 模 后 ， 第 一 种 方式 无 疑 
会 为 管理 员 带 来 不 小 的 负担 ， 但 其 对 于 保障 集群 安全 运行 却 又 必 不 可 
少 。 第 二 种 方式 降低 了 管理 员 的 工作 量 ， 却 也 损失 了 PKI 本 喘 所 具有 
的 诸多 优势 。 综 合 上 述 两 种 方案 ， 取 长 补 短 之 后 ，Kubernetes 采 用 了 
一 种 新 的 方案 : 由 kubelet 目 行 生 成 私 铀 和 证 书签 署 请 求 ， 而 后 发 送 给 
集群 上 的 证 书签 署 进 程 (CA) ， 由 管理 员 验 证 请 求 后 予以 签署 或 直接 
控制 妖 进 程 目 动 统一 签署 。 这 种 方式 即 为 Kubelet TLS Bootstrapping 机 
制 ， 它 实 现 了 前 述 第 一 种 方式 的 功能 ， 却 基本 上 不 会 增加 管理 员工 作 


里 


然而 ， 启 用 了 kubelet bootstrap 功 能 之 后 ， 任 何 kubelet 进 程 都 可 以 
| 器 API Server 发 起 签证 请 求 并 加 入 到 集群 中 ， 包 括 那 些 来 自 于 非 计划 或 
非 授权 主机 的 kubelet， 这 必 将 增 大 管理 等 证 操作 时 的 识别 工作 量 。 此 
时 ， 职 需要 配合 使 用 某 种 认证 机 制 对 发 出 请 求 的 kubelet 加 以 认证 ， 而 
后 仅 放行 那些 通过 认证 的 签证 请 求 。API Server 使 用 了 一 个 基于 认证 令 
牌 对 “system: bootstrappers” 组 内 的 用 户 完 成 认证 的 认证 器 。controller- 
manager 会 用 到 这 个 用 户 组 配置 默认 的 审批 控制 器 (approval 
controller) 适用 的 审批 范围 ， 它 依赖 于 由 管理 员 将 此 token 正 确 绑 定 于 
RBAC 和 有 策略 ， 以 限制 其 仅 能 用 于 签证 操作 相关 的 流程 之 中 。 


名 提示 。 kubeadm 启 用 了 方 点 加 入 集群 时 的 证 书 自 动 签署 功 
能 ， 因 此 加 入 过 程 在 kubeadm join 命 令 成 功 后 即 完 成 。 


请 求证 书 时 ，kubelet 要 使 用 含有 bootstrap token 的 kubeconfig 文 件 
| 器 kube-apiserver 发 送 请 求 ， 此 kubeconfig 在 credentials 中 指定 要 调用 的 
token 文 件 名 称 必须 是 kubelet-bootstrap。 若 指定 的 kubeocnfig 配 置 文件 
不 存在 ， 则 kubelet 会 转 而 使 用 bootstrap token 从 API Server 中 目 动 请 求 
证 书 。 证 书 请 求 审批 通过 后 ，kubelet 把 接收 到 的 证 书 和 私 钥 的 相关 信 
县 存储 于 --kubeconfig 选 项 指定 的 文件 中 ， 而 证 书 和 私 钥 文件 则 存储 于 - 
-Cert-dir 选 项 指定 的 目录 下 。 


kube-controller-manager 内 部 有 一 个 用 于 证 书 颁 发 的 控制 循环 ， 它 
是 采用 了 类 似 于 cfssl 签 证 器 格式 的 目 动 签证 器 ， 颁 发 的 所 有 证 书 都 仪 
有 一 年 有 效 期 限 。 签 证 依赖 于 CA 提供 加 密 组 件 文 撑 ， 此 CA 还 必须 被 
kube-apiserver 的 “--client-ca-file” 选 项 指定 的 CA 信任 以 用 于 认证 。 


Kubernetes 1.8 之 后 的 版 本 中 使 用 的 csrapproving 审 批 控 制 右 内 置 于 
kube-controller-manager 中 ， 并 有 旦 默认 为 局 用 状态 。 此 审批 控制 如 使 用 
SubjectAccessview API 确 认 给 定 的 用 户 是 否 有 权限 请 求 CSR (证 书签 署 
请 求 ) ， 而 后 再 根据 授权 结果 判定 是 否 予 以 签署 。 不 过 ， 为 了 避免 同 
内 建 的 审批 器 并 不 显 式 拒绝 CSR， 而 只 是 忽略 
和 


10.4 基于 角色 的 访问 控制 : RBAC 


RBAC (Role-Based Access Control， 基 于 角色 的 访问 控制 ) 是 一 种 
新 型 、 灵 活 且 使 用 广泛 的 访问 控制 机 制 ， 它 将 权限 授予 "角色 ” (role) 
这 一 点 有 别 于 传统 访问 控制 机 制 中 将 权限 直接 赋予 使 用 者 的 方 
本- 


在 RBAC 中 ， 用 户 (User) 就 是 一 个 可 以 独立 访问 计算 机 系统 中 的 
数据 或 者 用 数据 表示 的 其 他 资源 的 主体 (Subject) 。 和 角色 是 指 一 个 组 
织 或 任务 中 的 工作 或 者 位 置 ， 它 代表 了 一 种 权利 、 资 格 和 贡 任 。 许 可 

(Permission) 就 是 允许 对 一 个 或 多 个 客体 (Object) 执行 的 操作 。 一 
个 用 户 可 经 授权 而 拥有 多 个 角色 ， 一 个 角色 可 由 多 个 用 户 构成 ;每 个 
角色 可 拥有 多 种 许可 ， 每 个 许可 也 可 授权 给 多 个 不 同 的 角色 。 每 个 操 
作 可 施加 于 多 个 客体 〈 受 探 对 象 ) ， 每 个 客体 也 可 以 接受 多 个 操作 。 
RBAC 中 的 动作 、 主 体 及 客体 如 图 10-7 所 示 。 


人 | " 
Subject Object 
图 10-7 RBAC 中 的 主体 、 动 作 及 客体 


如 其 名 字 所 示 ，RBAC 的 基于 “角色 ” (role) 这 一 核心 组 件 实现 了 
权限 指派 ， 具 体 实 现 中 ， 它 为 账号 赋予 一 到 多 个 角色 从 而 让 其 具有 角 
色 之 上 的 权限 ， 其 中 的 账号 可 以 是 用 户 账 号 、 用 户 组 、 服 务 账号 及 其 
相关 的 组 等 ， 而 同时 关联 至 多 个 角色 的 账号 所 拥有 的 权限 是 多 个 角色 
之 上 的 权限 集合 。RBAC 中 的 用 户 、 和 角色 及 权限 的 关系 如 图 10-8 所 示 。 


N 
action (verb) > 
Vy 


图 10-8 RBAC 中 的 用 户 、 角 色 及 权限 


10.4.1 RBAC 授 权 插 件 


RBAC 是 一 种 操作 授权 机 制 ， 用 于 界定 “ 谁 ” (subject) 能 够 或 不 能 
够 “操作 ”(verb) 哪个 或 哪 类 “对 象 ”(object) 。 动 作 的 发 出 者 即 “ 主 
体 ”， 通 常 以 “账号 ?为 载体 ， 它 既 可 以 是 常规 用 户 (User Account) ， 世 
可 以 是 服务 账号 (Service Account) 。“ 操 作 ”(verb) 用 于 表明 要 执行 
的 具体 操作 ， 包 括 创 建 、 删 除 、 修 改 和 查看 等 ， 对 应 于 kubect 来 说 ， 
它 通 党 由 create、apply、delete、update、patch、edit 和 get 等 子 命令 来 给 
出 。 而 “客体 ” 则 是 指 操作 施加 于 的 目标 实体 ， 对 Kubernetes API 来 说 主 
要 是 指 各 类 的 资源 对 象 以 及 非 资源 型 URL 。 


@ Kubernetes 自 1.5 版 起 引入 RBAC，1.6 版 本 中 将 其 升级 
为 Beta 级 别 ， 并 成 为 kubeadm 安 装 方式 下 的 默认 选项 。 而 后 ， 直 到 1.8 版 
本 ， 它 才 正 式 升 级 为 stable 级 别 。 

相对 于 ABAC 和 Webhook 等 授权 机 制 来 襄 ，RBAC 具 有 如 下 优势 。 

1) 对 集群 中 的 资源 和 非 资 源 型 URL 的 权限 实现 了 完整 覆盖 。 


2) 整个 RBAC 完 全 由 少数 几 个 API 对 象 实现 ， 而 且 同 其 他 API 对 象 
一 样 可 以 用 kubectl 或 API 调 用 进行 操作 。 

3) 支持 权限 的 运行 时 调整 ， 无 须 重 新 启动 API Server。 

API Server 是 RESTful 风 格 的 API， 各 类 客户 端 基于 HTTP 的 请 求 报 
文 〈 首 部 ) 发 送 身份 认证 信息 并 由 认证 插件 完成 身份 验证 ， 而 后 通过 
HTTP 的 请 求 方法 指定 对 目标 对 象 的 操作 请 求 并 由 授权 插件 进行 授权 检 
查 ， 而 操作 的 对 象 则 是 借助 URL 路 径 指定 的 REST 资 源 。 


图 10-9 对 比 给 出 了 HTTP Verb 和 Kubernetes APIServer Verb 的 对 应 关 


HTTPverb request verb 

create 

get (for individual resources), list (for collections) 
PUT update 
PATCH patch 


DELETE 


delete (for individual resources), deletecollection (for collections) 


图 10-9 HTTP Verb 与 API Server Verb 
图 10-10 所 描述 的 过 程 中 ， 运 行 于 API Server 之 上 的 授权 插件 RBAC 
负责 确定 某 账号 是 否 有 权限 对 目标 资源 发 出 指定 的 操作 ， 它 们 都 属 
于 “许可 ” (permission) 类 型 的 授权 ， 不 存在 任何 “拒绝 ”权限 。 


筷 
人 \ 
Human User GET 人 
HEAD /api/vl/pods/pod! 
PUI /aplvl/pods/pod2 
POST /apUVV1/SserVlces/SVc1 
EEEGEEy | 
DELETE 


Pod 
Service Account 


图 10-10 ”Kubernetes RBAC 们 要 模型 


RBAC 授 权 插 件 支持 Role 和 ClusterRole 两 类 角色 ， 其 中 Role 作 用 于 
名 称 空间 级 别 ， 用 于 定义 名 称 空 间 内 的 资源 权限 集合 ， 而 ClusterRole 册 
用 于 组 织 集群 级 别 的 资源 权限 集合 ， 它 们 都 是 标准 的 API 资 源 类 型 。 一 
般 来 说 ，ClusterRole 的 许可 授权 作用 于 整个 集群 ， 因 此 常用 于 控制 Role 
无 法 生效 的 资源 类 型 ， 这 包括 集群 级 别 的 资源 (如 Nodes) 、 非 资源 类 
型 的 端点 (如 /healthz) 和 作用 于 所 有 名 称 空间 的 资源 (例如 ， 跨 名 称 
空间 获取 任何 资源 的 权限 ) 。 


对 这 两 类 角色 进行 赋 权 时 ， 需 要 用 到 RoleBinding 和 
ClusterRoleBinding 这 两 种 资源 类 型 。RoleBinding 用 于 将 Role 上 的 许可 
权限 绑 定 到 一 个 或 一 组 用 户 之 上 ， 它 隶属 于 且 仅 能 作用 于 一 个 名 称 罕 
间 。 绑 定时 ， 可 以 引用 同一 名 称 中 的 Role， 也 可 以 引用 集群 级 别 的 
ClusterRole。 而 ClusterRoleBinding 则 把 ClusterRole 中 定义 的 许可 权限 绑 
定 在 一 个 或 一 组 用 户 之 上 ， 它 仅 可 以 引用 集群 级 别 的 ClusterRole 。 
Role、RoleBinding、ClusterRole 和 ClusterRoleBinding 的 关系 如 图 10-11 
所 示 。 


Cluster scope (resource that aren 't namespaced) 


Namespace A 


RoleBinding 


Namespace B 


RoleBinding 


图 10-11 Role、RoleBinding、ClusterRole 和 ClusterRoleBinding 


一 个 名 称 空间 中 可 以 包含 多 个 Role 和 RoleBinding 对 象 ， 类 似 地 ， 
集群 级 别 也 可 以 同时 存在 多 个 ClusterRole 和 ClusterRoleBinding 对 象 。 而 
一 个 账户 也 可 经 由 RoleBinding 或 ClusterRoleBinding 关 联 至 多 个 角色 ， 
从 而 具有 多 重 许可 授权 。 


10.4.2 Role 和 RoleBinding 


Role 仅 是 一 组 许可 (permission) 权限 的 集合 ， 它 描述 了 对 哪些 资 
源 可 执行 何 种 操作 ， 资 源 配 置 清 单 中 使 用 rules 字 段 藤 套 授权 规则 。 下 
面 是 一 个 定义 在 testing 名 称 空间 中 的 Role 对 象 的 配置 清单 示例 ， 它 设 
定 了 读 取 、 列 出 及 监视 Pod 和 Service 资 源 的 许可 权限 : 


kind: Role 
apiVersion: rbac.authorization.k8s.io/v1 
metadata: 

namespace: testing 

name: pods-reader 


rules: 
- apiGroups: [""] # "" 表示 core API group 
resources: ["pods", "pods/l1o0g"] 


verbs: ["get", "list", "watch"] 


类 似 上 面 的 Role 对 象 中 的 rules 也 称 为 PolicyRule， 用 于 定义 策略 规 
则 ， 不 过 它 不 包含 规则 应 用 的 目标 ， 其 可 以 内 般 的 字段 包含 如 下 几 


de 


1) apiGroups<[]string>: 包含 了 资源 的 API 组 的 名 称 ， 支 持 列表 格 
式 指定 的 多 个 组 ， 空 串 〈"") 表示 核心 组 。 


2) resourceNames<[]string>: 规则 应 用 的 目标 资源 名 称 列表 ， 可 
选 ， 缺 省 时 意味 着 指定 资源 类 型 下 的 所 有 资源 。 


3) resources<[]string>: 规则 应 用 的 目标 资源 类 型 组 成 的 列表 ， 例 
如 pods、deployments、daemonsets、roles 等 ，ResourceAll 表 示 所 有 资 
源 。 


4) verbs<[]string>: 可 应 用 至 此 规则 匹配 到 的 所 有 资源 类 型 的 操 
作 列 表 ， 可 用 选项 有 get、1list、create、update、Ppatch、watch、Pproxy、 
redirect、delete 和 deletecollection; 此 为 必 选 字段 。 


5) nonResourceURLs<[]string>: 用 于 定义 用 户 应 该 有 权限 访问 的 
网 址 列表 ， 它 并 非 名 称 空间 级 别 的 资源 ， 因 此 只 能 应 用 于 ClusterRole 


和 ClusterRoleBinding， 在 Role 中 提供 此 字段 的 目的 仅 为 与 ClusterRole 
在 格式 上 兼容 。 


绝 大 多 数 资 源 均 可 通过 其 资源 类 型 的 名 称 引 用 ， 
如 “pods” 或 “services” 等 ， 这 些 名 字 与 它们 在 API endpoint 中 的 形式 相 
同 。 不 过 ， 有 些 资 源 类 型 还 支持 子 资源 (subresource) ， 例 如 Pod 对 象 
的 /log，Node 对 象 的 /status 等 ， 它 们 的 URL 格 式 通 常 形 如 如 下 表示 : 


GET /api/vi/namespaces/{namespace}/pods/{name}/log 


在 RBAC 角 色 定义 中 ， 如 果 要 引用 这 种 类 型 的 子 资源 ， 则 需要 使 
用 “resource/subre-source“ 的 格式 ， 如 上 面 示例 规则 中 的 “pods/log”。 田 
外 ， 还 可 以 通过 直接 给 定 资 源 名 称 (resourceName) 来 引用 特定 的 资 
源 ， 此 时 文 持 使 用 的 操作 通常 仅 为 get、delete、update 和 patch， 也 可 使 
用 这 四 个 操作 的 子 集 实 现 更 小 范围 的 可 用 操作 限制 。 


除了 编写 配置 清单 创建 Role 资源 之 外 ， 还 可 以 直接 使 用 "kubectl 
create role” 命 令 进 行 快速 创建 ， 例 如 ， 下 面 的 命令 在 testing 名 称 空间 中 
创建 了 一 个 名 为 services-admin 的 角色 : 


~]$ kubectl1 create role services-admin --verb="*" --resource="services,servic 
es/*" -n testing 


将 清单 中 的 Role 资 源 也 创建 于 集群 上 之 后 ，testing 名 称 空间 中 就 
有 了 pods-reader 和 services-admin 两 个 角色 ， 但 角色 本 寻 并 不 能 作为 动 
作 的 执行 主体 ， 它 们 需要 “ 绑 定 ”(\Role-Binding) 到 主体 (如 user、 
group 或 service account) 之 上 才能 发 生 作用 。 


RoleBinding 用 于 将 Role 中 定义 的 权限 赋予 一 个 或 一 组 用 户 ， 它 由 
一 组 主体 ， 以 及 一 个 要 引用 来 赋予 这 组 主体 的 Role 或 ClusterRole 组 
成 需要 注意 的 是 ，RoleBinding 仅 能 够 引用 同一 名 称 空 间 中 的 Role 对 
象 完 成 授权 ， 例 如 ， 下 面 配置 清单 中 的 RoleBinding 于 testing 名 称 空 间 
中 将 pods-reader 角 色 赋 给 了 用 户 kube-user1， 从 而 使 得 kube-user1 拥 了 
此 角色 之 上 的 所 有 许可 授权 : 


kind: RoleBinding 
apiVersion: rbac.authorization.k8s.io/v1 


metadata: 
name: resources-reader 
namespace: testing 
subjects: 
- kind: User 
name: kube-user1 
apiGroup: rbac.authorization.k8s.io 
roleRef: 
kind: Role 
name: pods-reader 
apiGroup: rbac.authorization.k8s.io 


将 此 RoleBinding 资 源 应 用 到 集群 中 ，kube-user1 用 户 便 有 了 读 取 
testing 名 称 空间 中 pods 资 源 的 权限 。 将 kubectl 的 配置 上 下 文 切 换 至 
kube-user1 用 户 ， 分 别 对 pods 和 services 资 源 发 起 访问 请 求 测试 ， 由 下 
面 的 命令 结果 可 以 看 出 ， 它 能 够 请 求 读 取 pods 资 源 ， 但 对 其 他 任何 资 
源 的 任何 操作 请 求 都 将 被 拒绝 : 


~]$ kubectl1 config use-context kube-useri@kubernetes 

Switched to context "kube-useriQ@kubernetes". 

~]$ kubect1 get pods -n testing 

No resources found. 

~]$ kubect1 get services -n testing 

Error from server (Forbidden): services is forbidden: User "kube-user1" cannot 
list services in the namespace "testing" 


RoleBinding 资 源 也 能 够 直接 在 命令 行 中 创建 。 例 如 ， 将 kubectl 的 
上 下 文 切 换 为 kubernetes-admin 用 户 ， 将 前 面 创建 的 services-admin 和 角色 
绑 定 于 kube-user1 之 上 ， 可 以 使 用 如 下 命令 进行 : 


~]$ kubectl1 config use-context kubernetes-admin@kubernetes 

~]$ kubectl1 create rolebinding admin-services --role=services-admin --user=kube- 
user1 -n testing 

rolebinding.rbac.authorization.k8s.io "admin-services" created 


再 次 切换 到 kube-user1 用 户 ， 进 行 services 资 源 的 访问 测试 ， 由 下 
面 的 命令 结果 可 知 ， 它 能 够 访问 services 资 源 ， 而 不 再 是 拒绝 权限 : 


~]$ kubectl1 config use-context kube-user1i@kubernetes 
~]$ kubect1 get services -n testing 
No resources found. 


事实 上 ， 通 过 admin- services 这 个 RoleBinding 绑 定 全 services- admin 
角色 之 后 ，kube-user1 用 户 拥有 管理 testing 名 称 空间 中 的 Service 资 源 的 
所 有 权限 。 帮 外 需要 注意 的 是 ， 虽 然 RoleBinding 不 能 路 名 称 空间 引用 
Role 贷 源 ， 但 主体 中 的 用 户 账号 、 用 户 组 和 服务 账号 却 不 受 名 称 空间 
的 限制 ， 因 此 ， 管 理 员 可 为 一 个 主体 通过 不 同 的 RoleBinding 资 源 绑 定 
多 个 名 称 空间 中 站 角色 。 


RoleBinding 的 配置 中 主要 包含 两 个 艇 套 的 字段 subjects 和 roleRef， 
其 中 ， subjects 的 值 征 一 个 对 象 列表 ， 用 于 给 出 要 绑 定 的 主体 ， 而 
roleRef 的 值 是 单个 对 象 ， 用 于 指 定 变 绑 定 的 Role 或 ClusterRole 资 从 源 。 
subjects 字 段 的 可 般 套 字段 具体 如 下 。 


"apiGroup<string> : 要 引用 的 主体 所 属 的 API 群 组 ， 对 于 
ServiceAccount 类 的 主体 来 说 默认 为 "， 而 User 和 Group 类 主体 的 默认 


值 为 "rbac.authorization.k8s.io" 。 


kind<string> : 要 引用 的 资源 ~ (主体 ) 所属 的 类 别 ， 可 用 值 
为 "User""Group" 和 "ServiceAccount" 三 个 ， 必 选 字 段 。 


name<string> : 引用 的 主体 的 名 称 ， 必 选 字段 。 


namespace<string> : 引用 的 主体 所 属 的 名 称 空间 ， 对 于 非 名 称 空 
间 类 型 的 主体 ， 如 "User" 和 "Group"， 其 值 必须 为 宝 ， 否 则 授权 揪 件 将 
返回 错误 信息 。 


roleRef 的 可 棚 套 字段 具体 如 下 。 


.apiGroup<string> : 引用 的 资源 (Role 或 ClusterRole) 所 属 的 API 
群 组 ， 必 选 字 段 。 

-kind<string> : 引用 的 资源 所 属 的 类 别 ， 可 用 值 为 Role 或 
ClusterRole， 必 选 字段 。 

name<string> : 引用 的 资源 的 名 称 。 


Role 和 RoleBinding 是 名 称 空间 级 别 的 资源 ， 它 们 仅 能 用 于 完成 单 
个 名 称 空间 内 的 访问 控制 ， 此 时 若 要 赋予 某 主 体 多 个 名 称 空间 中 的 访 
问 权 限 ， 丈 不 得 不 逐个 名 称 空间 地 进行 。 男 外 还 有 一 些 资源 其 本 喘 并 


不 属于 名 称 空 间 (如 PersistentVolume、NameSpace 和 Node 等 ) ， 甚 至 
还 有 一 些 非 资源 型 的 URL 路 径 (如 /healthz 等 ) ， 对 此 类 资源 的 管理 显 
然 无 法 在 名 称 空 间 级 别 完成 ， 此 时 束 需 要 用 到 另外 两 个 集群 级 别 的 资 
源 类 型 ClusterRole 和 ClusterRoleBinding 。 


10.4.3 ”ClusterRole 和 ClusterRoleBinding 


集群 级 别 的 角色 资源 ClusterRole 资 源 除 了 能 够 管理 与 Role 资源 一 样 
的 许可 权限 之 外 ， 还 可 以 用 于 集群 级 组 件 的 授权 ， 配 置 方式 及 其 在 
rules 字 段 中 可 内 退 的 字段 也 与 Role 资源 类 似 。 下 面 的 配置 清单 示例 中 定 
义 了 ClusterRole 资 源 nodes-reader， 它 拥有 访问 集群 的 节点 信息 的 权 
限 : 


kind: ClusterRole 
apiVersion: rbac.authorization.k8s.io/vi 
metadata: 
name: nodes-reader 
rules: 
- apiGroups: [""] 
resources: ["nodes"] 
verbs: ["get", "watch", "list"] 


ClusterRole 是 集群 级 别 的 资源 ， 它 不 属于 名 称 空间 ， 故 在 此 处 其 配 
置 不 应 该 使 用 metadata.namespace 字 段 ， 这 也 可 以 通过 获取 nodes-reader 
的 状态 信息 来 进行 验证 。kube-userl 用 户 此 前 绑 定 的 pods-reader 和 
services-admin 和 角色 属于 名 称 空 间 ， 它 们 无 法 给 予 此 用 户 访 问 集 群 级 别 
nodes 资 源 的 权限 。 


RoleBinding 也 能 够 将 主体 绑 定 至 ClusterRole 资 源 之 上 ， 但 仅 能 屿 
予 用 户 访问 Role-Binding 资 源 本 身 所 在 的 名 称 空间 之 内 可 由 ClusterRole 
赋予 的 权限 ， 例 如 ， 在 ClusterRole 具 有 访问 所 有 名 称 空间 的 ConfigMap 
资源 权限 时 ， 通 过 testing 名 称 空 间 的 RoleBinding 将 其 绑 定 至 kube-user1 
用 户 ， 则 kube-user1 用 户 就 具有 了 访问 testing 名 称 空间 中 的 ConfigMap 资 
源 的 权限 ， 但 不 能 访问 其 他 名 称 空间 中 的 ConfigMap 资 源 。 不 过 ， 奋 代 
助 ClusterRoleBinding 进 行 绑 定 ， 则 kube-userl 就 具有 了 所 有 相关 名 称 空 
间 中 的 资源 的 访问 权限 ， 如 图 10-12 所 示 。 
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岁 10-12 RoleBinding 与 ClusterRoleBinding 


因此 ， 一 种 常见 的 做 法 是 集群 管理 员 在 集群 艺 围 内 预先 定义 好 一 
组 访问 名 称 空间 级 别 资 源 权 限 的 ClusterRole 资 源 ， 而 后 在 多 个 名 称 空 间 
中 多 次 通过 RoleBinding 引 用 它们 ， 从 而 让 用 户 分 别 具 有 不 同名 称 空间 
上 的 资源 的 相应 访问 权限 ， 完 成 名 称 空间 级 别 权限 的 快速 授予 。 当 
然 ， 如 采 通 过 ClusterRoleBinding 引 用 这 类 的 ClusterRole， 则 相应 的 用 户 
即 拥有 了 在 所 有 相关 名 称 空间 上 的 权限 。 


集群 级 别 的 资源 nodes、persistentvolumes 等 资源 ， 以 及 非 资 源 型 的 
URL 不 属于 名 称 空 间 级 别 ， 故 此 通过 RoleBinding 绑 定 至 用 户 时 无 法 完 
成 访问 授权 。 事 实 上 ， 所 有 的 非 名 称 空间 级 别 的 资源 都 无 法 通过 
RoleBinding 绑 定 至 用 户 并 赋予 用 户 相关 的 权限 ， 这 些 是 属于 
ClusterRoleBinding 的 功能 。 


另外 ， 除 了 名 称 空间 及 集群 级 别 的 资源 之 外 ，Kubernetes 还 有 
着 /api、/apis、/healthz、/swaggerapi 和 /version 等 非 资源 型 URL， 对 这 些 
URL 的 访问 也 必须 事先 获得 相关 的 权限 。 同 集群 级 别 的 资源 一 样 ， 它 
们 也 只 能 定义 在 ClusterRole 中 ， 且 需要 基于 ClusterRoleBinding 进 行 授 


权 。 不 过 ， 对 此 类 资源 的 读 取 权 限 已 经 由 系统 默认 的 名 称 同 为 System: 
discovery 的 ClusterRole 和 ClusterRoleBinding 两 个 资 源 目 动 设 定 。 下 面 的 
命令 显示 了 system: discovery ClusterRole 的 相关 信息 : 


~]$ kubect] get clusterrole System:discovery -0 yaml 
apiVersion: rbac.authorization.k8s.io/vi 
kind: ClusterRole 
metadata: 
name: system:discovery 


rules: 

- nonResourceURLs: 
- /api 
- /api/* 
- /apis 
- /apis/* 
- /healthz 
- /swagger-2.0.0.pb-vi 
- /swagger .json 
- /swaggerapi 
- /swaggerapi/* 
- /version 
verbs: 
- get 


nonResourceURLs 字 上 段 给 出 了 相关 的 URL 列 表 (不 同 版 本 的 
Kubernetes 系 统 上 的 显示 可 能 略 有 区 别 ) ， 人 允许 的 访问 权限 仅 有 “get" 一 
用 了 此 资源 的 ClusterRoleBinding 的 相关 信息 如 下 面 的 命令 及 其 

结果 所 示 : 


~]$ kubect] get clusterrolebindings system:discovery -0 yaml 
apiVersion: rbac.authorization.k8s.io/vi 
kind: ClusterRoleBinding 
metadata: 
name: system:discovery 


roleRef: 
apiGroup: rbac.authorization.k8s.io 
kind: ClusterRole 
name: system:discovery 

subjects: 

- apiGroup: rbac.authorization.k8s.io 
kind: Group 
name: system:authenticated 

- apiGroup: rbac.authorization.k8s.io 
kind: Group 
name: system:unauthenticated 


由 命令 的 输出 结果 可 知 ， 它 绑 定 了 system: authenticated 和 
system: unauthencated 两 个 组 ， 这 品 括 了 所 有 的 用 户 账号 ， 因 此 所 有 用 


户 默 认 均 有 权限 请 求 读 取 这 些 资源 ， 任 何 发 往 API Server 的 此 类 端点 读 
取 请 求 都 会 得 到 啊 应 。 和 定义 其 他 类 型 的 访问 权限 ， 其 方法 可 参照 
system: discovery 这 个 ClusterRole 资 源 进行 。 例 如 ， 下 面 的 ClusterRole 
资源 示例 定义 了 对 非 资 源 型 URL 路 径 /healthz 的 读 写 访问 权限 : 


apiVersion: rbac.authorization.k8s.io/vi 
kind: ClusterRole 
metadata: 
name: healthz-admin 
rules: 
- NonResourceURLs: 
- /healthz 
verbs: 
- get 
- create 


另外 ， 非 资源 型 URL 的 授权 规则 与 资源 权限 的 授权 规则 可 定义 在 
同一 个 ClusterRole 中 ， 它 们 同属 于 mles 字 段 中 的 对 象 。 


10.4.4 “聚合 型 ClusterRole 


Kubernetes 目 1.9 版 本 开始 文 持 在 rules 字 段 中 先 套 aggregationRule 字 
段 来 整合 其 他 的 ClusterRole 对 象 的 规则 ， 这 种 类 型 的 ClusterRole 的 权 
限 受 控 于 控制 器 ， 它 们 由 所 有 被 标签 选择 絮 匹 配 到 的 用 于 聚合 的 
ClusterRole 的 授权 规则 合并 生成 。 下 面 是 一 个 示例 ， 它 定义 了 一 个 标 
签 选 择 器 用 于 挑选 匹配 的 ClusterRole: 


kind: ClusterRole 
apiVersion: rbac.authorization.k8s.io/v1 
metadata: 
name: monitoring 
aggregationRule: 
clusterRoleSelectors: 
- matchLabels: 
rbac.example.com/aggregate-to-monitoring: "true" 
rules: [] 


任何 能 够 被 示例 中 的 资源 的 标签 选择 器 匹配 到 的 ClusterRole 的 相 
关 规 则 都 将 一 同 合 并 为 它 的 授权 规则 ， 后 续 新 增 的 ClusterRole 资 源 亦 
是 如 此 。 因 此 ， 聚 合 型 ClusterRole 的 规则 会 随 着 标签 选择 器 的 匹配 结 
果 而 动态 变化 。 下 面 即 是 一 个 能 匹配 到 此 聚合 型 ClusterRole 的 男 一 个 
ClusterRole 的 示例 : 


kind: ClusterRole 
apiVersion: rbac.authorization.k8s.io/v1 
metadata: 

name: monitoring-endpoints 

labels: 

rbac.example.com/aggregate-to-monitoring: "true" 

# These rules will be added to the "monitoring" role. 
rules: 
- apiGroups: [""] 

Resources: ["services", "endpoints", "pods"] 

verbs: ["get", "list", "watch"] 


创建 这 两 个 资源 ， 而 后 查看 聚合 型 ClusterRole 资 源 monitoring 的 相 


天 权限 信息 ， 由 下 面 的 命令 结果 可 知 ， 它 所 拥有 的 权限 包含 了 
ClusterRole 资 源 monitoring-endpoints 的 所 有 授权 : 


~]$ kubect1l create -f monitoring.yaml -f monitoring-endpoints.yaml 
~]$ kubectl1 get clusterrole monitoring -0 yaml 
aggregationRule: 

clusterRoleSelectors: 

- matchLabels: 

rbac.example.com/aggregate-to-monitoring: "true" 

apiVersion: rbac.authorization.k8s.io/v1 
kind: ClusterRole 
metadata: 

name: monitoring 


rules: 
- apiGroups: 


resources: 
- Services 
- endpoints 
- pods 
verbs: 

- get 

- list 

- watch 


事实 上 ，Kubernetes 系 统 上 面向 用 户 的 内 建 ClusterRole admin 和 
edit 也 是 聚合 型 Cluster-Role， 因 为 这 可 以 使 得 默认 角色 中 包含 目 定义 
资源 的 相关 规则 ， 例 如 ， 由 CustomResource-Definitions 或 Aggregated 
API 服 务 器 提供 的 规则 等 。 


10.4.5 面 癌 用 户 的 内 建 ClusterRole 


API Server 内 建 了 一 组 默认 的 ClusterRole 和 ClusterRoleBinding 以 预 
留 系 统 使 用 ， 其 中 大 多 数 都 以 “system: ”为 前 级 。 男 外 还 有 一 些 非 
以 “system: ”为 前 缀 的 默认 的 Role 资源 ， 它 们 是 为 面 癌 用 户 的 需求 而 设 
计 的 ， 包 括 超级 用 户 角色 (cluster-admin) 、 用 于 授权 集群 级 别 权 限 的 
ClusterRoleBinding (cluster-status) 以 及 授予 特定 名 称 空 间 级 别 权 限 的 
RoleBinding (admin、edit 和 view) ， 如 图 10-13 所 示 。 掌 握 这 些 默认 的 
内 建 ClusterRole 对 后 期 按 需 创建 用 户 并 快速 配置 权限 至 关 重 要 。 
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图 10-13 ”内 建 的 面向 用 户 的 ClusterRole 


内 建 的 ClusterRole 资 源 cluster-admin 拥 有 管理 集群 所 有 资源 的 权 
限 ， 它 基于 同名 的 ClusterRoleBinding 资 源 绑 定 到 了 “system: masters” 组 
上 ， 这 意味 着 所 有 素 属 于 此 组 的 用 户 都 将 具有 集群 的 超级 管理 权限 。 
kubeadm 安 装 设 定 集群 时 目 动 创建 的 配置 文件 /etc/kubernetes/admin.conf 
中 定义 的 用 户 kubernetes-admin 使 用 证 书 文件 /etc/kubernetes/pki/piserver- 
kubelet-client.crt| 可 API Server 进 行 验证 。 而 此 证 书 的 Subject 信 息 
为 “/O=system: masters/CN=kubernetes-admin”， 进 行 认证 时 ，CN 的 值 
可 作为 用 户 名 使 用 ， 而 0 的 值 将 作为 用 户 所 属 组 名 使 用 ， 因 此 ， 
kubernetes-admin 具 有 集群 管理 权限 。 


于 是 ， 为 Kubernetes 集 群 额外 目 定 义 超 级 管理 员 的 方法 至 少 具有 两 
种 : 一 种 是 创建 用 户 证 书 ， 其 Subject 中 O 的 值 为 “system: masters”， 男 
一 种 是 创建 ClusterRoleBinding 将 用 户 绑 定 至 cluster-admin 之 上 。 其 具体 


的 实现 方法 均 可 参照 10.4.4 生 和 本 中 的 内 容 略 加 变通 而 实现 ，cluster- 
status 的 使 用 方法 与 此 类 同 ， 有 所 区 别 的 仅 在 于 权限 本 吴 。 


另外 ， 在 多 租户 、 多 项 目 或 多 环境 等 使 用 场景 中 ， 用 户 通常 应 该 
获取 名 称 空间 级 别 绝 大 多 数 资 源 的 管理 、 只 读 或 编辑 权限 ， 这 类 权限 
的 快速 授予 可 通过 在 指定 的 名 称 空 间 中 创建 RoleBinding 资 源 引用 内 建 
的 ClusterRole 资 源 admin、view 或 edit 来 进行 。 例 如 ， 在 名 称 空间 dev 中 
创建 一 个 RoleBinding 资 源 ， 它 将 引用 admin， 并 绑 定 至 kube-user1， 使 
得 此 用 户 具 有 管理 dev 名 称 空间 中 除了 名 称 空间 本 身 及 资源 配额 之 外 的 
所 有 资源 的 权限 : 


~]$ kubectl] create rolebinding dev-admin --clusterrole=admin --user=kube-user1 -n 
dev 


而 后 切换 至 kube-user1 用 户 在 dev 中 创建 一 个 资源 ， 并 查看 相关 的 
信息 进行 访问 测试 ， 如 下 面 的 命令 所 示 : 


~]$ kubect] create deployment myapp-deploy --image=ikubernetes/myapp:v1 -n dev 
deployment .extensions "myapp-deploy" created 
~]$ kubect] get all -n dev 


如 果 需 要 授予 的 是 编辑 或 只 读 权 限 ， 则 仅 需要 将 创建 RoleBinding 
时 引用 的 ClusterRole 相 应 地 修改 为 edit 或 view 即 可 。 表 10-1 总 结 了 典型 
的 面向 用 户 的 内 建 ClusterRole 及 其 功用 。 


表 10-1 面 癌 用 户 的 内 建 ClusterRole 资 源 
默认 的 ClusterRole 说 明 


cluster-admin system:masters 组 授予 超级 管理 员 在 任何 对 象 上 执行 任何 操作 的 权限 


以 RoleBinding 机 制 访问 指定 名 称 空间 的 所 有 资源 ， 包 括 名 称 
admin None 5 i A i 
空间 的 Role 和 RoleBinding， 但 不 包括 资源 配置 和 名 称 空间 本 身 
。 允许 读 写 访 问 一 个 名 称 空间 内 的 绝 大 多 数 资 源 ， 但 不 允许 查 
edit None a 2 
看 或 修改 Role 或 RoleBinding 
, 允许 读 取 一 个 名 称 空间 内 的 绝 大 多 数 资源 ， 但 不 允许 查看 
View None Spe 和 RE 
Role 或 RoleBinding， 以 及 secret 资源 


10.4.6 ”其 他 的 内 建 ClusterRole 和 
ClusterRoleBinding 


API Server 会 创建 一 组 默认 的 ClusterRole 和 ClusterRoleBinding， 大 
多 数 都 以 “system: ”为 前 级 ， 被 系统 基础 架构 所 使 用 ， 修 改 这 些 资 源 
将 会 导致 集群 功能 不 正常 。 例 如 ， 如 果 修 改 了 为 kubelet 赋 权 
的 “system: node” 这 一 ClusterRole， 则 将 会 导致 kubelet 无 法 工作 。 所 有 
默认 的 ClusterRole 和 ClusterRoleBinding 都 打 了 标 
签 “kubernetes.io/bootstrapping=rbac-defaults”。 


每 次 局 动 时 ，API Server 都 会 目 动 为 默认 的 ClusterRole 重 新 赋予 缺 
失 的 权限 ， 以 及 为 默认 的 ClusterRoleBinding 绑 定 缺 失 的 Subject。 这 种 
机 制 给 了 集群 从 意外 修改 中 目 动 恢 复 的 能 力 ， 以 及 升级 版 本 后 ， 上 自动 
将 ClusterRole 和 ClusterRoleBinding 升 级 到 满足 新 版 本 需求 的 能 力 。 


名 提示 “必要 时 ， 在 默认 的 ClusterRole 或 ClusterRoleBinding 上 
设置 annnotation 中 “rbac.authorization.kubernetes.io/autoupdate“ 属 性 的 值 
为 “false” 即 可 禁止 此 种 自动 恢复 功能 。 


Kubemetes 内 建 的 其 他 ClusterRole 和 ClusterRoleBinding 下 有 很 多 ， 
它们 绝 大 多 数 都 是 用 于 系统 本 身 的 诸多 组 件 结合 RBAC 获 得 最 小 化 但 
完整 的 资源 访问 授权 。 它 们 大 体 可 分 为 专用 于 核心 的 组 件 、 附 加 的 组 
件 、 资 源 发 现 及 controller-manager 运 行 核心 控制 循环 (control loop) 等 
几 个 类 型 ， 如 system: kube-sheduler 、system: kube-controller- 
manager 、 system: node 、 system: node-proxier 和 system: kube-dns 


等 ， 大 多 数 都 可 以 做 到 见 名 知 义 ， 这 里 不 再 逐一 给 出 说 明 。 


10.5 Kubernetes Dashboard 


Dashboard 是 Kubernetesf]Web GUI， 可 用 于 在 Kubernetes 集 群 上 部 
署 容器 化 应 用 、 应 用 排 障 、 管 理 集群 本 身 及 其 附加 的 资源 等 。 它 常 被 
管理 员 用 于 集群 及 应 用 速 览 、 创 建 或 修改 单个 资源 (如 Deployments 、 
Jobs 和 DaemonSets 等 ) ， 以 及 扩 展 Deployment、 局 动 滚动 更 新 、 重 局 
Pod 或 使 用 部 署 癌 导 部 署 一 个 新 应 用 等 。 


© 注意 ” Dashboard 依赖 于 Heapster 或 Metrics Server 完 成 指标 数 
据 的 采集 和 可 视 化 。 


Dashboard 的 认证 和 授权 均 可 由 Kubernetes 集 群 实 现 ， 它 目 身 仅 是 
一 个 代理 ， 所 有 的 相关 操作 都 将 发 给 API Server 进 行 ， 而 非 由 
Dashboard 自 行 完 成 。 目 前 它 支 持 使 用 的 认证 方式 有 承载 令 牌 (bear 
token) 和 kubeconfig 两 种 ， 在 访问 之 前 需要 准备 好 相应 的 认证 凭证 


10.5.1 部署 HTTPS 通 信 的 Dashboard 


Dashboard 1.7 (不 含 ) 之 前 的 版 本 在 部 署 时 直接 赋予 了 管理 权限 ， 
这 种 方式 可 能 存在 安全 风险 ， 因 此 ，1.7 及 之 后 的 版 本 默认 在 部 署 时 仅 
定义 了 运行 Dashboard 所 需要 的 最 小 权限 ， 仅 能 够 在 Master 主 机 上 通 
过 “kubectl proxy” 命 令 创建 代理 后 于 本 机 进行 访问 ， 它 默认 禁止 了 来 自 
于 其 他 任何 主机 的 访问 请 求 。 知 要 绕 过 “kubect proxy" 百 接 访 问 
Dashboard， 则 需要 在 部 署 时 提供 证 书 以 便 与 客户 端 进行 通信 时 建立 一 

安全 的 HTTPS 连 接 。 证 书 既 可 由 公信 CA 和 颁发， 也 可 目 行 使 用 openssl 
或 cfssl 一 类 的 工具 来 创建 


部 署 Dashboard 时 会 从 Secrets 对 象 中 加 载 所 需要 的 私 铀 和 证 书 文 
需要 事先 准备 好 相关 的 私 钥 、 证 书 和 Secrets 对 象 。 需 要 注意 的 

下 面 的 命令 需要 以 管理 员 的 身份 在 Master 节 点 上 运行 ， 否 则 将 无 法 
访问 到 ca key 文 件 : 


~]# (umask 077; openssl genrsa -out dashboard.key 2048 ) 
~]# openssl req -new -key dashboard.key -out dashboard.csr -subj 
"/0=iLinux/CN=dashboard" 
~]# openssl] x509 -req -in dashboard.csr -CA /etc/kubernetes/pki/ca.crt \ 

-CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out dashboard.crt -days 
3650 


接 下 来 ， 基 于 生成 的 私 钥 和 证 书 文 件 创建 名 为 kubernetes- 
dashboard-certs 的 Opaque 类 型 的 Secret 对 象 ， 其 键 名 分 别 为 dashboard.key 
和 dashboard.crt: 


~]$ kubect] create secret generic kubernetes-dashboard-certs \ 
-n kube-system --from-file=dashboard.crt=./dashboard.crt \ 
--from-file=dashboard,.key=./dashboard.key -n kube-system 


Secret 对 象 准 备 完成 后 即 可 部 署 Dashboard。 若 无 其 他 自 定 义 部 署 的 
需要 ， 可 直接 基于 在 线 资源 配置 清单 。 不 过 ， 资 源 清 单 中 也 创建 了 
Secrets 对 象 ， 因 此 ， 它 可 能 会 发 出 警告 信息 Ss 默认 创建 的 
Service 对 象 类 型 为 ClusterIP， 它 仅 和 在 Pod 客 户 记 山中 访问 ， 若 需 在 集群 
外 通过 浏览 器 访问 Dashboard， 则 需要 修改 其 类 型 为 NodePort 再 进行 创 


建 ， 或 者 在 创建 后 通过 修改 命令 进行 设 定 。 这 里 采取 直接 在 线 创 建 
并 修改 其 Service 对 象 kubernetes-dashboard 的 类 型 的 方式 : 


~]$ kubectl apply -f 

https://raw.githubusercontent,.com/kubernetes/dashboard/master/ 
src/deploy/recommended/kubernetes-dashboard.yaml 

~]$ kubect] patch svc kubernetes-dashboard -p '{"spec":{"type":"NodePort"}}' -n 
kube-system 


确认 其 使 用 的 NodePort 之 后 便 可 在 集群 外 通过 浏览 船 进行 访问 


~]$ kubect] get svc kubernetes-dashboard -n kube-system 
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE 
kubernetes-dashboard NodePort 10.110.145.88 <none> 443:31999/TCP 2h 


天 -一 


图 10-14 即 为 其 默认 显示 的 登录 页 面 ， 文 持 的 认证 方式 为 kubeconfig 
和 token ( 令 牌 ) 两 种 。 
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Kubernetes 仪表 板 


© Kubeconfig 


请 选择 您 已 配置 用 来 访问 集群 的 kubeconfig 文件 ， 请 浏览 配置 对 多 个 集 

群 的 访问 一 节 ， 了 解 更 多 关于 如 何 配置 和 使 用 kubeconfig 文件 的 信息 
〇 令 牌 

每 个 服务 账号 都 有 一 条 保密 字典 保存 持 有 者 令 牌 ， 用 来 在 仪表 板 登 录 ,请 

浏览 验证 一 节 ， 了 解 更 多 关于 如 何 配置 和 使 用 持 有 者 令 牌 的 信息 


图 10-14 ”Dashboard 认 证 界面 


Dashboard 是 运行 于 Pod 对 象 中 的 应 用 ， 其 连接 API Server 的 账户 尺 应 
为 ServiceAccount 类 型 ， 因 此 ， 用 户 在 登录 界面 提供 的 用 户 账号 须 得 是 
此 类 账户 ， 而 且 访 问 权 限 也 取决 于 kubeconfig 或 token 认 证 时 的 
ServiceAccount 用 户 的 权限 。ServiceAccount 的 集群 资源 访问 权限 取决 于 
它 绑 定 的 角色 或 集群 角色 ， 例 如 ， 为 登录 的 用 户 授 权 集 群 级 别 的 管理 
权限 时 可 直接 绑 定 内 建 的 集群 角色 cluster-admin， 授 权 名 称 空间 级 别 的 


管理 权限 时 ， 可 直接 绑 定 内 建 的 集群 角色 admin。 当 然 ， 也 可 以 直接 自 
定义 RBAC 的 角色 或 集群 角色 ， 并 进行 绑 定 授权 ， 例 如 集群 级 别 的 只 谈 
权限 或 名 称 空 间 的 只 读 权 限 。 


10.5.2 ”配置 token 认 证 


集群 级 别 的 管理 操作 依赖 于 集群 管理 员 权 限 ， 例 如 ， 管 理 持久 存 
储 卷 和 名 称 空 间 等 资源 ， 内 建 的 cluster-admin 集 群 角色 拥有 相关 的 全 音 
权限 ， 创 建 ServiceAccount 并 将 其 绑 定 其 上 即 可 完成 集群 管理 员 授权 。 
而 用 户 通过 相应 的 ServiceAccount 的 token 信 息 完 成 Dashboard 认 证 也 残 
能 扮演 起 Dashboard 接 口上 的 集群 管理 员 角 色 。 例 如 ， 下 面 创建 一 个 名 
为 dashboard-admin 的 ServiceAccount， 并 完成 集群 角色 绑 定 : 


~]$ kubect1l create serviceaccount dashboard-admin -n kube-system 
~]$ kubect1l create clusterrolebinding dashboard-admin --clusterrole=cluster-admin 
\ 

--Serviceaccount=kube-system:dashboard-admin 


创建 ServiceAccount 对 象 时 ， 它 会 自动 为 用 户 生 成 用 于 认证 的 
token 信 息 ， 这 一 点 可 以 从 与 其 相关 的 Secrets 对 象 上 获取 : 


~]$ ADMIN_SECRET=$(kubect1 -n kube-system get secret | awk '/^dashboard- 
admin/{print $1}') 
~]$ kubectl1 describe secrets $ADMIN_ SECRET -n kube-system kube-system 


Name : dashboard-admin-token-jfcd6 
Namespace: kube-system 
token: eyJhbGci0iJSUzI1NiIsImtpZCI6IiJ9.eyJpc3Mi0iJrdwWJlcm5ldGVzL3NlcnzZz 


pY2VhY2NvdwW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2Ui0iJrd 
WJ1LXN5c3R1bSIsImt1iYmVyb...... 


对 上 面 获取 到 的 token 在 登录 界面 选择 令 牌 认证 方式 ， 并 键入 token 
令 牌 即 要 登录 的 Dashboard， 其 效果 如 图 10-15 所 示 。 


上 面 认证 时 用 到 的 令 牌 将 采用 base64 的 编码 格式 ， 且 登录 时 需要 
将 原 内 容 贴 入 文本 框 ， 存 储 及 操作 都 有 其 不 便 之 处 ， 建 议 用 户 将 它 存 
入 kubeconfig 配 置 文件 中 ， 通 过 kubeconfig 的 认证 方式 进行 登录 。 


10.5.3 ”配置 kubeconfig 认 证 


kubeconfig 是 认证 信息 承载 工具 ， 它 能 够 存 入 私 铀 和 证 书 ， 或 者 认 
证 令 牌 等 作为 用 户 的 认证 配置 文件 。 为 了 说 明 如 何 配置 一 个 仅 具 有 特 
定名 称 空间 管理 权限 的 登录 账号 ， 这 里 再 次 创建 一 个 新 的 
ServiceAccount 用 于 管理 默认 的 default 名 称 空间 ， 并 将 之 绑 定 于 admin 集 
群 角色 ， 其 操作 过 程 与 10.5.2 节 的 方式 相似 : 


~]$ kubect] create serviceaccount def-ns-admin -n default 
~]$ kubect] create rolebinding def-ns-admin --clusterrole=admin \ 
--Serviceaccount=default:def-ns-admin 
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图 10-15 ”Dashboard 主 面板 


下 面 分 步 又 说 明 如 何 创建 所 需 的 kubeconfig 文 件 。 第 一 步 ， 初 始 化 
集群 信息 ， 提 供 API Server 的 URL， 以 及 验证 API Server 证 书 所 用 到 的 
CA 证 书 等 。 


~]$ kubect] config set-cluster kubernetes --embed-certs=true --server="https:// 
172.16.0.70:6443" \\ 
--Ccertificate-authority=/etc/kubernetes/pki/ca.crt --kubeconfig=./def-ns- 


admin. 
kubeconfig 


ara 


第 二 获取 def-ns-admin 的 token， 并 将 其 作为 认证 信息 。 由 于 直 
Os 因此 ， 下 面 使 用 了 “base64-d” 命 令 将 
其 解 丰 : 


~]$ DEFNS_ADMIN_SECRET=$(kubect1 -n default get secret | awk '/^def-ns-admin 
/{print $1}') 


~]$ DEFNS_ ADMIN_TOKEN=$(kubectl -n default get secret ${DEF_NS_ ADMIN_ SECRET} 和 
-0 jsonpath={.data.token}|base64 -d) 


~]$ kubect] config set-credentials def-ns-admin --token=${DEFNS ADMIN_TOKEN} \ 
--kubeconfig=,./defns-admin.kubeconfig 


第 三 步 ， 设 置 context 列 表 ， 定 义 一 个 名 为 def-ns-admin 的 context: 


~]$ kubectl] config set-context def-ns-admin --cluster=kubernetes \\ 
--User=defns-admin --kubeconfig=./defns-admin.kubeconfig 


后 指定 要 使 用 的 context 为 前 面 定义 的 名 为 def-ns-admin 的 ] 


人 


~]$ kubect] config use-context def-ns-admin --kubeconfig=./defns-admin.kubeconfig 


到 此 为 止 ， 一 个 用 于 Dashboard 登 录 认 证 的 default 名 称 空 间 的 管理 


员 账 号 配置 文件 已 经 设置 完成 ， 将 文件 复制 到 远程 客户 端 上 即 可 用 于 
登录 认证 。 


配置 token 认 证 和 kubeconfig 认 证 时 创建 ServiceAccount 和 完成 集群 
角色 的 绑 定 以 及 角色 绑 定 的 过 程 也 可 以 使 用 资源 配置 清单 文件 来 实 
现 ， 相 关 的 文件 可 在 本 章 的 代码 清单 目录 中 获得 ， 分 别 为 dashboard- 
admin.yaml 和 def-ns-admin.yaml， 可 用 它们 取代 前 面相 关 的 创建 命令 。 
天 于 Dashboard 的 使 用 这 里 就 不 再 多 做 介绍 了 了， 读者 根 据 界 面 提示 信息 
很 快 束 能 掌握 共用 法 。 


10.6 ” 准 入 控制 带 与 应 用 示例 


在 经 由 认证 插件 和 授权 插件 分 别 完成 喘 份 认 证 和 权限 检查 之 后 ， 
准 入 控制 器 将 拦截 那些 创建 、 更 新 和 删除 相关 的 操作 请 求 以 强制 实现 
控制 硕 中 定义 的 功能 ， 包 括 执行 对 象 的 语义 验证 、 设 置 缺 失 字段 的 默 
认 值 、 限 制 所 有 容 郁 使 用 的 镜像 文件 必须 来 目 某 个 特定 的 Registry、 检 
查 Pod 对 象 的 资源 需求 是 否 超出 了 指定 的 限制 范围 等 。 


但 是 准 入 控制 辟 的 相关 代码 必须 要 由 管理 员 编 译 进 kube-apiserver 
中 才能 使 用 ， 实 现 方式 缺乏 灵活 性 。 于 是 ，Kubernetes 目 1.7 版 本 引入 
了 Initializers 和 External Admission Webhooks 来 党 试 突破 此 限制 ， 而 且 
自 1.9 版 本 起 ，External Admission Webhooks 又 被 分 为 Mutating- 
AdmissionWebhook 和 ValidatingAdmissionWebhook 两 种 类 型 ， 分 别 用 于 
在 API 中 执行 对 象 配置 的 “变异 ”和 “验证 ?操作 。 在 具体 的 代码 实现 上 ， 
一 个 准 入 控制 絮 可 以 是 “验证 "型 “变异” 型 或 兼 具 此 两 项 功能 。 变 异 
控制 器 可 以 修改 他 们 许可 的 对 象 ， 而 验证 控制 颖 则 一 般 不 会 。 


在 具体 运行 时 ， 准 入 控制 可 分 为 两 个 阶段 ， 第 一 个 阶段 串 行 运行 
各 变异 型 控制 硕 ， 第 二 个 阶段 串 行 运行 各 验证 型 控制 厦 ， 在 此 过 程 
中 ， 一 旦 任 一 阶段 中 的 任何 控制 右 拒 绝 请 求 ， 则 立即 拒绝 整个 请 求 ， 
并 回 用 户 返 回 错误 。 


10.6.1 LimitRange 资 源 与 LimitRanger 准 入 控制 妖 
虽然 用 户 可 以 为 容器 指定 资源 需求 及 资源 限制 ， 但 未 予 指定 资源 
限制 属性 的 容器 应 用 很 有 可 能 因 故 吞 掉 所 在 工作 节点 上 的 所 有 可 用 计 
算 资源 ， 因 此 妥当 的 做 法 是 使 用 LimitRange 资 源 在 每 个 名 称 空间 中 为 
每 个 容器 指定 最 小 及 最 大 计算 资源 用 量 ， 甚 至 是 设置 默认 的 计算 资源 
需求 和 计算 资源 限制 。 在 名 称 空 间 上 定义 了 LimitRange 对 象 之 后 ， 客 
户 端 提交 创建 或 修改 的 资源 对 象 将 受到 LimitRanger 控 制 器 的 检查 ， 任 
何 违反 LimitRange 对 象 定义 的 资源 最 大 用 量 的 请 求 将 被 直接 拒绝 。 


LimitRange 资 源 文 持 限 制 容 器 、Pod 和 PersistentVolumeClaim 三 种 
资源 对 象 的 系统 资源 用 量 ， 其 中 Pod 和 容 絮 主要 用 于 定义 可 用 的 CPU 和 
内 存 资源 范围 ， 而 PersistentVolume-Claim 则 主要 定义 存储 空间 的 限制 
范围 。 下 面 的 配置 清单 以 容 吉 的 CPU 资源 为 例 ，default 用 于 定义 默认 
的 资源 限制 ，defaultRequest 定 义 默 认 的 资源 需求 ，min 定 义 最 小 的 资 
源 用 量 ， 而 最 大 的 资源 用 量 既 可 以 使 用 max 给 出 固定 值 ， 也 可 以 使 用 
maxLimitRequestRatio 设 定 为 最 小 用 量 的 指定 倍数 : 


apiVersion: v1 
kind: LimitRange 
metadata: 
name: cpu-limit-range 
spec: 
limits: 
- default: 
cpu: 1000m 
defaultRequest: 
cpu: 1000m 
min: 


cpu: 2000m 
maxLimitRequestRatio: 
cpu: 4 
type: Container 


将 配置 清单 中 的 资源 创建 于 集群 上 的 default 名 称 空间 中 ， 而 后 即 
可 使 用 describe 命 令 查 看 相关 资源 的 生效 结果 。 创 建 不 同 的 Pod 对 象 对 
J ` 最 小 资源 限制 及 最 大 资源 限制 分 别 进行 测试 以 验证 其 限制 机 
[| o 


首先 ， 创 建 一 个 仅 包 舍 一 个 容 需 且 没 有 黑 认 系统 货源 需求 和 限制 
的 Pod 对 象 : 


~]$ kubect1l run limit-pod1i--image=ikubernetes/myapp:v1 --restart=Never 


Pod 对 和 象 limit- podl 的 许 细 信号 中 ， 容 絮 状态 信息 段 中 ，CPU 资 源 
J 用 定 为 如 下 配置 ， 这 正好 名 村 合 了 LimitRange 对 象 中 定义 的 默认 


Limits: 
cpu: 1 

Requests: 
cpu: 1 


若 Pod 对 象 设 定 的 系统 资源 需求 量 小 于 LimitRange 中 的 最 小 用 量 限 
制 ， 则 会 触发 LimitRanger 准 入 控制 絮 拒 绝 相 关 的 请 求 : 


~]$ kubectl1 run limit-pod2 --image=ikubernetes/myapp:vi \ 
--restart=Never --requests='cpu=400m' 

Error from server (Forbidden): pods "limit-pod4" is forbidden: minimum cpu usage 
per Container is 500m, but request is 400m., 


看 Pod 对 象 设 定 的 系统 资源 限制 量 大 于 LimitRange 中 的 最 大 用 量 限 
制 ， 则 一 样 会 触发 LimitRanger 准 入 控制 器 拒绝 相关 的 请 求 : 


~]$ kubectl1 run limit-pod3 --image=ikubernetes/myapp:vi --restart=Never -- 
limits= 
'chu=3000m" 
Error from server (Forbidden): pods "limit-pod2" is forbidden: maximum cpu 
Usage per Container is 2, but limit is 3. 


事实 上 ， 在 LimitRange 对 象 中 设置 的 默认 的 资源 需求 和 资源 限 
制 ， 同 最 小 资源 用 量 及 最 大 资源 用 量 限制 能 够 组 合 出 多 种 不 同 的 情 
形 ， 不 同 组 合 场景 下 真正 生效 的 结果 也 会 存在 不 小 的 差异 。 男 外 ， 内 
存 资 源 及 PVC 资 源 限制 的 实现 与 CPU 资源 大 同 小 异 ， 鉴 于 篇 幅 有 限 ， 
这 部 分 就 留待 读者 自行 验证 了 。 


10.6.2 ResourceQuota 资 源 与 准 入 控制 硕 


尽管 LimitRange 资 源 能 限制 单个 容器 、Pod 及 PVC 等 相关 计算 资源 
或 存储 资源 的 用 量 ， 但 用 户 依 然 可 以 创建 数量 众多 的 此 类 资源 对 象 进 
而 侵占 所 有 的 系统 资源 。 于 是 ，Kubernetes 提 供 了 ResourceQuota 资 源 
用 于 定义 名 称 空间 的 对 象 数 量 或 系统 资源 配额 ， 它 支持 限制 每 种 资源 
类 型 的 对 象 总 数 ， 以 及 所 有 对 象 所 能 消耗 的 计算 资源 及 存储 资源 总 量 
等 。ResourceQuota 准 入 控制 器 负责 观察 传 入 的 请 求 ， 并 确保 它 没 有 违 
反 相 应 名 称 空 间 中 ResourceQuota 对 象 定义 的 任何 约束 。 


于 是 ， 管 理 员 可 为 每 个 名 称 空 间 分 别 创建 一 个 ResourceQuota 对 

象 ， 随 后 ， 用 户 在 名 称 空间 中 创建 资源 对 象 ，ResourceQuota 准 入 控制 
铬 将 跟踪 使 用 情况 以 确保 它 不 超过 相应 ResourceQuota 对 象 中 定义 的 系 
统 资 源 限 制 。 用 户 创建 或 更 新 资源 的 操作 违反 配额 约束 将 导致 请 求 失 
败 ，API Server 以 HTTP 状 态 代码 “403FORBIDDEN” 作 为 响应 ， 并 显示 
一 条 消息 以 提示 可 能 违反 的 约束 。 不 过 ， 在 名 称 空间 上 局 用 了 CPU 和 
内 存 等 系统 资源 的 配额 后 ， 用 户 创建 Pod 对 象 时 必须 指定 资源 需求 或 

限制 ， 否 则 ， 会 触发 ResourceQuota 准 入 控制 器 拒绝 执行 相应 的 操 


ResourceQuota 对 和 象 可 限制 指定 名 称 空间 中 非 终 止 状态 的 所 有 Pod 
对 象 的 计算 资源 需求 及 计算 资源 限制 总 量 。 


:cpu 或 requests.cpu: CPU 资源 需求 的 总 量 限 额 。 
memory 或 requests.cpu: 内 存 资 源 需求 的 总 量 限额 。 
limits.cpu: CPU 资源 限制 的 总 量 限额 。 
limits.memory: 内 存 资 源 限 制 的 总 量 限 额 。 
| ResourceQuota 对 象 文 持 限制 特定 名 称 空间 中 可 以 使 用 的 PVC 数 量 
和 这 些 PVC 资 源 的 空间 大 小 总 量 ， 以 及 特定 名 称 空 间 中 可 在 指定 的 
StorageClass 上 使 用 的 PVC 数 量 和 这 些 PVC 资 源 的 总 数 : 


:requests.storage: 所 有 PVC 存 储 需 求 的 总 量 限额 。 


.persistentvolumeclaims: 可 以 创建 的 PVC 忆 数 。 


‘<s torage-class-name>.storageclass.storage.k8s.io/requests.storage: 


指定 存储 类 上 可 使 用 的 所 有 PVC 存 储 需 求 的 总 量 限额 。 


‘<s torage-class- 
name>.storageclass.storage.k8s.io/persistentvolumeclaims: 指定 存储 类 上 


可 使 用 的 PVC 总 数 。 
:requests.ephemeral-storage: 所 有 Pod 可 用 的 本 地 临时 存储 需求 的 


Ek 
wl 


limits.ephemeral-storage: 所 有 Pod 可 用 的 本 地 临时 存储 限制 的 总 


wl 


在 1.9 版 本 之 前 ，ResourceQuota 支 持 在 名 称 空间 级 别 的 有 限 的 几 种 
资源 集 上 设 定 对 象 计数 配额 ， 如 Pods、Services 和 ConfigMAPs 等 ， 而 
上 自 1.9 版 本 起 支持 以 “count/<resource>.<group>” 的 格式 支持 对 所 有 资源 
类 型 对 象 的 计数 配额 ， 如 count/deployments.apps 、count/ 


deployments.extensions 和 count/services 等 。 


下 面 的 配置 清单 示例 定义 了 一 个 ResourceQuota 资 源 对 象 ， 它 配置 
了 计算 资源 、 存 储 资 源 及 对 象 计数 几 个 维度 的 限额 : 


apiVersion: v1 
kind: ResourceQuota 


metadata: 
name: quota-example 
spec: 
hard: 
pods: "5" 


requests.cpu: "1" 
requests.memory: 16Gi 

limits,.cpu: "2" 

limits.memory: 26Gi 
count/deployments.apps: "1" 
count/deployments.extensions: "1" 
persistentvolumeclaims: "2" 


创建 完成 后 ，describe 命 令 可 以 打印 其 限额 的 生效 情况 ， 例 如 ， 将 
上 面 的 ResourceQuota 对 象 创 建 于 test 名 称 空 间 中 ， 其 打印 结果 如 下 所 
和 小: 


~]$ kubectl1 describe quota quota-example -n test 


Name: quota-example 
Namespace: test 
Resource Used Hard 
count/deployments.apps 0 1 
count/deployments.extensions 0 1 
limits.cpu 0 2 
limits.memory 0 2G1 
persistentvolumeclaims 0 2 
pods 0 5 
requests,.cpu 0 1 
requests.memory 0 16i 


在 test 名 称 空间 中 创建 Deployment 等 对 象 即 可 进行 配额 测试 ， 例 
如 ， 下 面 的 命令 创建 了 一 个 有 着 3 个 Pod 副 本 的 Deployment 对 象 myapp- 
deploy: 


~]$ kubectl1 run myapp-deploy --image=ikubernetes/myapp:v1 --replicas=3 \ 
--hnamespace=test --requests='cpu=200m,memory=256Mi' -- 
limits='cpu=500m, memory=256Mi'" 


创建 完成 后 ，test 名 称 空间 上 的 ResourceQuota 对 和 象 quota-example 的 
各 配置 属性 也 相应 地 变 成 了 如 下 状态 : 


Resource Used Hard 
count/deployments.apps 1 2 
count/deployments.extensions 1 2 
limits.cpu 1200m 2 
limits.memory 768Mi 2G1i 
persistentvolumeclaims 0 2 
pods 3 5 
requests,.cpu 500m 1 
requests.memory 640Mi 161i 


此 时 ， 再 扩展 myapp-deploy 的 规模 则 会 很 快 遇 到 某 一 项 配额 的 限 
制 而 导致 扩展 受阻 。 由 分 析 可 知 ， 将 Pod 副 本 数量 扩展 至 5 个 就 会 达到 
人 而 导致 第 5 个 扩展 失败 。 读 者 可 目 行 扩展 并 测试 其 结 


需要 注意 的 是 ， 资 源 配 额 仪 对 那些 在 ResourceQuota 对 象 创建 之 后 
生成 的 对 象 有 效 ， 对 已 经 存在 的 对 象 不 会 产生 任何 限制 。 而 且 , 一 旦 
局 用 了 计算 资源 需求 和 计算 资源 限制 配额 ， 那 么 创建 的 任何 Pod 对 和 象 


都 必须 设置 此 两 类 属性 ， 否 则 Pod 对 象 的 创建 将 会 被 相应 的 
ResourceQuota 对 象 所 阳 止 。 无 须 手 动 为 每 个 Pod 对 象 设 置 此 两 类 属性 
时 ， 可 以 使 用 LimitRange 对 象 为 其 设置 默认 值 。 


每 个 ResourceQuota 对 象 上 还 文 持 定义 一 组 适用 范围 (scope) ， 用 
于 定义 其 配额 仅 生 效 于 这 组 适用 范围 交集 内 的 对 象 ， 目 前 可 用 的 适用 
范围 包括 Terminating、NotTerminating、BestEffort 和 NotBestEffort， 具 
体 说 明 如 下 。 


"Terminating: 匹配 .spec.activeDeadlineSeconds 的 属性 值 大 于 等 于 0 
的 所 有 Pod 对 象 。 


.NotTerminating: 匹配 .spec.activeDeadlineSeconds 的 属性 值 为 空 的 
所 有 Pod 对 象 。 


:BestEffort 匹配 所 有 位 于 BestEffort QoS 类 别 的 Pod 对 象 。 
-NotBestEffort” 人 匹配 所 有 非 BestEffort QoS 类 别 的 Pod 对 象 。 


另外 ， 自 1.8 版 本 起 ， 管 理 员 即 可 以 设置 不 同 的 优先 级 类 别 
(PriorityClass) 来 创建 Pod 对 象 ， 而 自 1.11 版 本 起 ，Kubernetes 开 始 支 
持 对 每 个 PriorityClass 对 象 分 别 设 定 资源 限额 ,管理 员 可 以 使 用 
ee ， 从 而 根据 Pod 对 象 的 优先 级 控制 Pod 资 源 对 系统 资 
产 的 消 箔 。 


10.6.3 PodSecurityPolicy 


PodSecurityPolicy (简称 PSP) 是 集群 级 别 的 资源 类 型 ， 用 于 控制 
用 户 在 配置 Pod 资 源 的 期 望 状态 时 可 以 设 定 的 特权 类 的 属性 ， 如 是 否 
可 以 使 用 特权 容 右 、 根 命名 空间 和 主机 文件 系统 ， 以 及 可 使 用 的 主机 
网 络 和 端口 、 卷 类 型 和 Linux Capabilities 等 。 不 过 ，PSP 对 象 定义 的 策 
略 本 身 并 不 会 直接 发 生 作用 ， 它 们 需要 经 由 PodSecurityPolicy 准 入 控制 
髓 检查 并 强制 生效 。 


不 过 ，PSP 谁 入 控制 句 默 认 是 处 于 未 启用 状态 的 ， 原 因 是 在 未 创 
建 任何 PSP 对 象 的 情况 下 启用 此 准 入 控制 絮 将 阻止 在 集群 中 创建 任何 
Pod 对 象 。 不 过 ，PSP 资 源 的 API 接 口 
\policy/vlbetal/podsecuritypolicy) 独立 于 PSP 准 入 控制 器 ， 因 此 管理 
员 可 以 事先 定义 好 所 需要 的 Pod 安 全 策略 ， 而 后 再 设置 kube-apiserver 启 
用 PSP 准 入 控制 器 。 不 当 的 Pod 安 全 策略 可 能 会 产生 难以 预料 的 副 作 
用 ， 因 此 请 确保 所 添加 的 任何 PSP 对 和 象 都 经 过 了 充分 的 测试 。 


局 用 PSP 准 入 控制 万 后 和 若 要 部 署 任 何 Pod 对 象 ， 则 相关 的 User 
Account 及 Service Account 必 须 全 部 获得 了 恰当 的 Pod 安 全 全 略 授权 。 
以 常规 用 户 的 身份 直接 创建 Pod 对 象 时 ，PSP 准 入 控制 絮 将 根据 账户 有 
权 使 用 的 Pod 安 全 策略 验证 其 凭据 。 关 不 存在 任何 策略 支持 Pod 对 和 象 安 
全 性 要 求 ， 则 会 拒绝 相关 的 创建 操作 。 而 基于 控制 器 (如 
Deployment) 创建 Pod 对 象 时 ，Kubernetes 会 根据 服务 账户 有 权 使 用 的 
Pod 安 全 策略 验证 Pod 的 Service Account 和 凭据 。 若 没有 策略 文 持 Pod 对 和 象 
的 安全 性 要 求 ， 则 Pod 控 制 絮 自身 能 够 成 功 创建 ， 但 Pod 对 象 不 会 。 


事实 上， 即便 是 在 局 用 了 PSP 准 入 控制 右 的 情况 下 创建 的 PSP 对 象 
也 依然 不 会 发 生效 用 ， 而 是 要 由 授权 插件 (如 RBAC) 将 “use” 操 作 权 
限 授 权 给 特定 的 Role 或 ClusterRole， 而 后 将 Use Account 或 Service 
Account 完 成 角色 绑 定 才 可 以 。 下 面 人 简单 说 明 一 下 设 定 重 要 的 Pod 安 全 
策略 ， 而 后 启用 PSP 准 入 控制 磊 使 其 生效 的 方法 。 


1. 设 置 特权 及 受 限 的 PSP 对 象 


一 般 说 来 ，system: masters 组 内 的 管理 员 用 户 、system: node 组 
内 的 kubelet， 以 及 kube-system 名 称 空间 中 的 Service Account 需 要 拥有 


创建 各 类 Pod 对 象 的 授权 ， 包 括 特 权 Pod 对 象 。 因 此 ， 首 移 要 创建 一 个 
特权 PSP， 授 予 相关 的 管理 员 权 限 。 一 个 示例 性 的 配置 清单 如 下 : 


apiVersion: policy/vibetali 
kind: PodSecurityPolicy 
metadata: 
name: privileged 
annotations: 
seccomp.security.alpha.kubernetes.io/allowedProfileNames: '*' 
spec: 
privileged: true 
allowPrivilegeEscalation: true 
allowedCapabilities: 
1 大 1 
VOLumes : 


二 


hostNetwork: true 


hostPorts : 
- min: 0 
max: 65535 


hostIPC: true 
hostPID: true 


runAsUser : 

rule: "RunAsAny 
seLinux: 

rule: 'RUuNAsAny' 
supplementalGroups: 

rule: "RunAsAny 
fsGroup: 


rule: 'RUuNAsAny' 


相应 地 ， 经 过 API Server 成 功 认 证 的 User Account 或 Service 
Account 多 数 都 应 该 具有 创建 非特 权 Pod 对 象 的 授权 ， 因 此 ， 它 们 应 该 
获取 受 限 的 安全 策略 。 下 面 的 配置 清单 定义 了 一 个 非特 权 的 安全 守 
略 ， 它 禁止 了 大 多 数 的 特权 操作 : 


apiVersion: policy/vibetali 
kind: PodSecurityPolicy 
metadata: 
name: restricted 
annotations: 
seccomp.security.alpha.kubernetes.io/allowedProfileNames: 'docker/default' 
apparmor.security.beta.kubernetes.io/allowedProfileNames: 'runtime/default' 
seccomp.security.alpha.kubernetes.io/defaultProfileName: 'docker/default' 
apparmor.security.beta.kubernetes.io/defaultProfileName: 'runtime/default' 
spec: 
privileged: false 
# Required to prevent escalations to root. 
allowPrivilegeEscalation: false 
# This is redundant with non-root + disallow privilege escalation, 
# but we can provide it for defense in depth. 
requiredDropCapabilities: 
- ALL 


# Allow core volume types. 
volumes: 
- 'configMap' 
‘emptyDir' 
"projected ' 
"Secret 
"downwardAPI' 
Assume that persistentVolumes set up by the cluster admin are safe to use. 
- 'persistentVolumeClaim' 
hostNetwork: false 
hostIPC: false 
hostPID: false 
runAsUser: 
# Require the container to run without root privileges. 
rule: 'MustRunAsNonRoot'" 
seLinux: 
# This policy assumes the nodes are using AppArmor rather than SELinux. 
rule: 'RUuNAsAny' 
supplementalGroups: 
rule: 'MustRunAs' 
ranges: 
# Forbid adding the root group. 
- min: 1 
max: 65535 
fsGroup: 
rule: 'MustRunAs' 
ranges: 
# Forbid adding the root group. 
- min: 1 
max: 65535 
readonlyRootFilesystem: false 


证 


将 上 述 两 个 配置 清单 中 定义 的 PSP 资 源 提 交 并 创建 于 API Server 之 
上 ， 随 后 便 可 授权 特定 的 Role 或 ClusterRole 资 源 通过 use 进 行 调 用 了 。 


2. 创 建 ClusterRole 并 完成 账户 绑 定 


创建 一 个 ClusterRole 对 象 psp: privileged， 授 权 其 可 以 使 用 名 为 
privileged 的 PSP 对 象 ， 并 创建 一 个 ClusterRole 对 象 psp: restricted， 授 
权 其 可 以 使 用 和 名 为 restricted 的 PSP 对 象 ， 如 下 面 的 配置 清单 所 示 : 


kind: ClusterRole 
apiVersion: rbac.authorization.k8s.io/v1 
metadata: 
name: psp:restricted 
rules: 
- apiGroups: ['policy'] 
resources: ['podsecuritypolicies'] 
verbs: ['use'] 
resourceNames: 
- restricted 


kind: ClusterRole 


apiVersion: rbac.authorization.k8s.io/v1 
metadata.: 
name: psp:privileged 
rules: 
- apiGroups: ['policy'] 
resources: ['podsecuritypolicies'] 
verbs: ['use'] 
resourceNames: 
- privileged 


而 后 创建 ClusterRoleBinding 对 象 ， 将 system: masters 、system: 
node 和 system: serviceaccounts: kube-system 组 的 账户 绑 定 至 psp: 
privileged， 让 它们 拥有 管理 员 权 限 ， 并 将 system: authenticated 组 内 的 
账户 绑 定 至 psp: restricted， 授 予 它 们 创建 普通 Pod 对 象 的 权限 : 


apiVersion: rbac.authorization.k8s.io/v1 
kind: ClusterRoleBinding 
metadata.: 
name: privileged-psp-user 
roleRef: 
apiGroup: rbac.authorization.k8s.io 
kind: ClusterRole 
name: psp:privileged 


subjects: 
- apiGroup: rbac.authorization.k8s.io 
kind: Group 


name: system:masters 
- apiGroup: rbac.authorization.k8s.io 
kind: Group 
name: system:node 
- apiGroup: rbac.authorization.k8s.io 
kind: Group 
name: system:serviceaccounts:kube-system 
kind: ClusterRoleBinding 
apiVersion: rbac.authorization.k8s.io/v1 
metadata: 
name: restricted-psp-user 
roleRef: 
kind: ClusterRole 
name: psp:restricted 
apiGroup: rbac.authorization.k8s.io 
subjects: 
- kind: Group 
apiGroup: rbac.authorization.k8s.io 
name: system:authenticated 


3. 启 用 PSP 准 入 控制 器 


待 上 述 步 又 完 成 之 后 ， 设 置 kube-apiserver 的 --enable-admission- 
plugins 选 项 ， 在 其 列表 中 添加 “PodSecurityPolicy” 项 目 ， 并 重启 kube- 


apiserver 便 能 启用 PSP 准 入 控制 侨 。 而 对 于 使 用 kubeadm 部 署 的 
Kubernetes 集 群 来 说 ， 编 辑 Master 玉 点 上 

的 /etc/kubernetes/manifests/kube-apiserver.yaml 配 置 清单 ， 在 其 --enable- 
admission-plugins 选 项 后 的 列表 上 添加 “PodSecurity- Policy” 项 目 ， 等 
kube-apiserver 相 关 的 Pod 对 象 自 动 重 构 完 成 之 后 即 会 启用 PSP 准 入 控制 
器 。 


随后 ， 创 建 拥 有 特权 securityContext 的 Pod 资 源 配 置 清单 ， 并 以 经 
过 认证 的 User Account 或 Service Account 分 别 创建 特权 和 非特 权 的 Pod 
对 象 便 能 验证 Pod 安 全 策略 的 效果 。 例 如 ， 为 前 面 章 节 中 创建 的 kube- 
user1 使 用 Rolebinding 对 和 象 在 test 名 称 空间 绑 定 至 名 为 admin 的 
ClusterRole 对 象 ， 授 予 其 test 名 称 空间 的 管理 员 权限 ， 而 后 再 由 其 洋 试 
创建 下 面 清单 中 定义 的 特权 Pod 对 和 象 : 


apiVersion: v1 
kind: Pod 
metadata: 
name: pod-with-securitycontext 
spec: 
containers: 
- name: busybox 
image: busybox 
imagePullPolicy: IfNotPresent 
command: ["/bin/sh","-c","sleep 86400"] 
securityContext: 
privileged: true 


将 上 面 的 配置 清单 保存 于 配置 文件 中 ， 如 pod-test.yaml， 而 后 进行 
创建 测试: 


~]$ kubect1 apply -f pod-test.yaml -n test 
Error from server (Forbidden): error when creating "pod-test.yaml": pods "pod- 
with - 

securitycontext" is forbidden: unable to validate against any pod security 
policy: 

[spec.containers[0].securityContext.privileged: Invalid value: true: 
Privileged containers 

are not allowed] 


命令 结果 显示 创建 操作 被 PSP 定 义 的 策略 所 拒绝 ， 因 为 kube-user1 
用 户 被 归 类 到 system: authenticated 组 中 ， 因 此 被 关联 到 了 restricted 安 
全 叶 略 上 。 移 除 配置 清单 中 的 security-Context 及 其 欲 套 的 字段 再 次 执 
行 创建 操作 即 可 成 功 完成 ， 感 兴趣 的 读者 可 目 行 测试 。 另 外 ， 读 者 可 


按 此 方式 授权 特定 的 用 户 拥 有 特定 类 型 的 Pod 对 和 象 创建 权限 ， 但 策略 
冲突 时 可 能 会 导致 意料 不 到 的 结 末 ， 因 此 任何 Pod 安 全 策略 在 生效 之 
前 请 务必 做 到 充分 测试 。 


10.7 “本章 小 结 


本 章 主要 讲解 了 Kubernetes 的 认证 、 授 权 及 准 入 控制 相关 的 话 
题 ， 其 中 重点 说 明了 以 下 内 容 。 


-Kubernetes 系 统 的 认证 、 授 权 及 准 入 控制 插件 的 工作 流程 。 
“Service Account 资 源 及 其 应 用 方式 。 

:HTTPS 客 户 端 证 书 认 证 及 其 在 kubectl 利 tls bootstrap 中 的 应 用 。 
.Role 及 RoleBinding 的 工作 机 制 及 应 用 方式 。 

.ClusterRole 及 ClusterRoleBinding 的 工作 机 制 及 其 应 用 方式 。 


.借助 默认 的 ClusterRole 及 ClusterRoleBinding 实 现 集群 及 名 称 空间 
级 别 权 限 的 快速 授予 。 


.Dashboard 及 其 分 级 权限 授予 。 


”一 使 用 LimitRange 闹 源 限制 名 称 空间 下 容器 、Pod 及 PVC 对 象 的 系统 
资源 限制 。 


-使 用 ResourceQuota 设 置 名 称 空间 的 总 资源 限制 。 
使 用 PodSecurityPolicy 设 置 创 建 Pod 对 象 的 安全 策略 。 


第 11 章 ”网 络 模型 与 网 络 全 略 


目 Docker 技 术 诞 生 以 来 ， 采 用 容器 技术 用 于 开发 、 测 试 甚至 是 生 
产 环境 的 企业 或 组 织 与 日 俱 增 。 然 而 ， 将 容 右 技术 应 用 于 生产 环境 时 
如 何 确定 合适 的 网 络 方案 依然 是 吏 竺 解决 的 最 大 问题 ， 这 也 曾 是 主机 
虚拟 化 时 代 的 著名 难题 之 一 ， 它 不 仅 涉 及 了 网 络 中 各 组 件 的 互 连 互 
通 ， 还 需要 将 容器 与 不 相关 的 其 他 容器 进行 有 效 阳 离 以 确保 其 安全 
性 。 本 章 将 主要 讲述 容 姻 网 络 模 型 的 进化 、Kubernetes 的 网 络 模 型 、 
和 营 用 网 络 插件 以 及 网 络 策略 等 相关 的 话题 。 


11.1 Kubernetes 网 络 模型 及 CNI 插 件 


Docker 的 传统 网 络 模型 在 应 用 至 日 趋 复 杂 的 实际 业务 场景 时 必 将 
导致 复杂 性 的 几何 级 数 上 升 ， 由 此 ，Kubernetes 设 计 了 一 种 网 络 模 
型 ， 它 要 求 所 有 容 絮 都 能 够 通过 一 个 磺 平 的 网 络 平面 直接 进行 通信 

(在 同一 IP 网 络 中 ) ， 无 论 它 们 是 否 运行 于 集群 中 的 同一 节点 。 不 
过 ， 在 Kubernetes 集 群 中 ， 卫 地 址 分 配 是 以 Pod 对 象 为 单位 ， 而 非 容 
右 ， 同 一 Pod 内 的 所 有 容器 共享 同一 网 络 名 称 空间 。 


(一 


DO 


11.1.1 Docker 容 器 的 网 络 模型 


Docker 容 名 网 络 的 原始 模型 主要 有 三 种 :Bridge (桥接 ) 、Host 
(主机 ) 及 Container (容器 ) 。Bridge 模 型 借助 于 虚拟 网 桥 设备 为 容器 

建立 网 络 连 返 ，Host 模 型 则 设 定 容器 直接 共享 使 用 市 点 主机 的 网 络 名 

尔 空 间 ， 而 Container 模 型 则 古 指 多 个 容器 共享 同一 个 网 络 名 称 空间 ， 


从 而 彼此 之 间 能 够 以 本 地 通信 的 方式 建立 连接 。 


Docker 守 护 进程 首次 启动 时 ， 它 会 在 当前 节点 上 创建 一 个 名 为 
docker0 的 桥 设备 ， 并 默认 配置 其 使 用 172.17.0.0/16 网 络 ， 该 网 络 是 
Bridge 模 型 的 一 种 实现 ， 也 是 创建 Docker 容 器 时 默认 使 用 的 网 络 模型 。 
如 图 11-1 所 示 ， 创 建 Docker 容 器 时 ， 默 认 有 四 种 网 络 可 供 选 择 使 用 ， 从 
而 表现 出 了 四 种 不 同类 型 的 容器 ， 有 具体 如 下 。 


.Closed container 〈 封 闭 式 容 器 ) : 此 类 容器 使 用 “None” 网 络 ， 它 
们 没有 对 外 通信 的 网 络 接口 ， 而 是 仅 具 有 IO 接口 ， 通 常 仅 用 于 不 需要 
网 络 的 后 端 作业 处 理 场 景 。 


.Bridged container (桥接 式 容 器 ) : 此 类 容器 使 用 “Bridge” 模 型 的 
网 络 ， 对 于 每 个 网 络 接口 ， 容 器 引擎 都 会 为 每 个 容器 创建 一 对 (两 
个 ) 虚拟 以 太 网 设备 ， 一 个 配置 为 容器 的 接口 设备 ， 男 一 个 则 在 节点 
主机 上 接 入 指定 的 虚拟 网 桥 设备 (默认 为 docker0) 。 


.Open container (开放 式 容器 ) : 此 类 容器 使 用 “Host* 模 型 的 网 
络 ， 它 们 共享 使 用 Docker 主 机 的 网 络 及 其 接口 。 


:Joined container (联盟 式 容 器 ) : 此 类 容器 共享 使 用 某 个 已 存在 的 
容器 的 网 络 名 称 空间 ， 即 共享 并 使 用 指定 的 容器 的 网 络 及 其 接口 。 
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图 11-1 Docker 容 絮 网 络 
上 述 的 容器 间 通 信 仪 揪 述 了 同一 太太 上 的 容 句 间 通 信 的 可 用 方 
案 ， 这 应 该 也 是 Docker 设 计 痢 早期 最 为 天 注 的 容 絮 通信 有 目标。 然而 ， 


在 生产 环境 中 使 用 容器 技术 时 ， 跨 市 点 的 容器 间 通 信友 倒 更 为 常见 ， 
可 根据 网 络 类 型 将 其 实现 方式 简单 划分 为 如 下 几 种 。 


-为 各 Docker 节 点 创建 物理 网 络 桥接 接口 ， 设 定 各 节点 上 的 容 顺 使 


用 此 桥 设备 从 而 直接 腔 露 于 物理 网 络 中 。 
-配置 各 季 点 上 的 容器 直接 共 译 使 用 其 证 点 的 网 络 名 称 空间 。 
行 通信 
第 三 种 方案 是 较为 流行 且 默 认 的 解决 方案 。 不 过 ， 此 种 方案 的 


-将 容器 接 入 指定 的 桥 设备 ， 如 docker0， 并 设置 其 借助 NAT 机 制 进 


IPAM (IP Address Management) 是 基于 容器 主机 本 地 范围 进行 的 ， 每 
个 节点 上 的 容器 都 将 从 同一 个 网 络 172.17.0.0/16 中 获取 IP 地 址 ， 这 就 意 


味 看 不 同 Docker 主 机 上 的 容 右 可 能 会 使 用 相同 的 地 址 ， 因 此 它们 也 整 


无 法 直接 通信 。 


解决 此 问题 的 通行 方式 是 为 NAT。 所 有 接 入 到 此 桥 设备 上 的 容器 
均 会 被 NAT 隐 藏 ， 它 们 发 往 Docker 主 机 外 部 的 所 有 流量 都 会 在 执行 过 
产地 址 转换 后 发 出 ， 并 且 默 认 古 无 法 直接 接收 市 点 之 外 的 其 他 主机 发 
来 的 请 求 的 。 知 要 接 入 Docker 主 机 外 部 的 流量 ， 则 需要 事先 通过 目标 
地 址 转换 甚至 额外 的 端口 转换 将 其 暴露 于 外 部 网 络 中 ， 如 图 11-2 所 示 。 


docker host docker host 
containerl ( container2 ) 
“ethoT Temol” 
EE / 
/| veth | | veth [一 
docker0 (172.17.0.0/16) docker0 (172.17.0.0/16) 
| | 目标 地 址 转换 ， 要 1 转换 
eth0 | eth0 
源 地 址 转换 


图 11-2 ”路 世 点 容 郁 间 的 通信 示例 图 


故此 ， 传 统 的 解决 方案 中 ， 多 地 点 上 的 Docker 容 如 间 通 信 依 赖 于 
NAT 机 制 转 发 实现 。 这 种 解决 方案 在 网 络 规模 庞大 时 将 变 得 极为 复 
杂 、 对 系统 货源 的 消耗 镑 大 且 转 发 效率 低下 。 此 外 ，docker host 的 端口 
也 走 一 种 黎 缺 货源 ， 静 仿 分 配 和 映射 极 易 导致 圳 突 ， 而 动态 分 配 叉 很 
容易 导致 模型 的 进一步 复 洒 化 。 


事实 上 ，Docker 网 络 也 可 借助 于 第 三 方 解 决 方案 来 规避 NAT 通 信 
模型 导致 的 复杂 化 问题 ， 后 来 还 发 布 了 CNM (Container Network 
Model) 规范 ， 现 在 已 经 被 Cisco Contiv、Kuryr、Open Virtual 
Networking (OVN) 、Project Calico、VMware 或 Weave 这 些 公 司 和 项 目 
所 采纳 。 不 过 ， 这 种 模型 被 采用 时 ， 也 残 属 于 了 容 需 编排 的 范畴 。 


11.1.2 ”Kubernetes 网 络 模 型 


Kubernetes 的 网 络 模型 主要 可 用 于 解决 四 类 通信 需求 : 同一 Pod 内 
容器 间 的 通信 (Container to Container) 、Pod 间 的 通信 (Pod to 
Pod) 、Service 到 Pod 间 的 通信 (Service to Pod) 以 及 集群 外 部 与 
Service 之 间 的 通信 (external to Service) 。 


(1) 容器 间 通 信 


Pod 对 象 内 的 各 容器 共享 同一 网 络 名 称 空间 ， 它 通常 由 构建 Pod 对 
象 的 基础 架构 容器 所 提供 ， 例 如 ， 由 pause 镜 像 启 动 的 容器 。 所 有 运行 
于 同一 个 Pod 内 的 容器 与 同一 主机 上 的 多 个 进程 类 似 ， 彼 此 之 间 可 通过 
lo 接口 完成 交互 ， 如 图 11-3 所 示 ，Pod P 内 的 Container1 和 Container2 之 间 
的 通信 有 即 为 容 姨 则 通信 。 


(2) Pod 间 通信 


各 Pod 对 和 象 需要 运行 于 同一 个 平面 网 络 中 ， 每 个 Pod 对 象 拥有 一 个 
集群 全 局 唯一 的 地 址 并 可 直接 用 于 与 其 他 Pod 进 行 通信 ， 如 图 11-3 中 的 
PodP 和 Pod Q 之 间 的 通信 。 此 了 网络 也 称 为 Pod 网 络 。 另 外 ， 运 行 Pod 的 
各 下 点 也 会 通过 桥接 设备 等 持 有 此 平面 网 络 中 的 一 个 卫 地 址 ， 如 图 11-3 
中 的 cbr0 接 口 ， 这 就 意味 着 Node 到 Pod 间 的 通信 也 可 在 此 网 络 上 直接 进 
行 。 因 此 ，Pod 间 的 通信 或 Pod 到 Node 间 的 通信 比较 类 似 于 同一 IP 网 络 
中 主机 间 进 行 的 通信 。 
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图 11-3” ”Pod 网 络 


此 类 通信 模型 中 的 通信 需求 也 是 Kubernetes 的 各 网 络 插件 需要 着 力 
解决 的 问题 ， 它 们 的 实现 方式 有 县 加 网 络 模型 和 路 由 网 络 模型 等 ， 流 
行 的 解决 方案 有 十 数 种 之 多 ， 例 如 前 面 使 用 到 的 flannel 。 


(3) Service 与 Pod 间 的 通信 


Service 资 源 的 专用 网 络 也 称 为 集群 网 络 (Cluster Network) ， 需 要 
在 局 动 kube-apiserver 时 经 由 “--service-cluster-ip-range” 选 项 进行 指定 ， 
如 10.96.0.0/12， 而 每 个 Service 对 象 在 此 网 络 中 均 拥 一 个 称 为 Cluster-IP 
的 固定 地 址 。 管 理 员 或 用 户 对 Service 对 象 的 创建 或 更 改 操作 由 API 
Server 存 储 完成 后 触发 各 世 点 上 的 kube-proxy， 并 根据 代理 模式 的 不 同 
将 其 定义 为 相应 和 点 上 的 iptables 规 则 或 ipvs 规 则 ， 借 此 完成 从 Service 的 
Cluster-IP 与 Pod-IP 之 间 的 报 文 转发 ， 如 图 11-4 所 示 。 


PodP A eo 加 和 A eth0 
| (Chent) | \ Se | Host X 
~、 Netfilter > 


> 
ti 


f 、\ 
| pod Q eth0 
| | Host Y 


图 11-4 ”Service 和 Pod 


(4) 集群 外 部 到 Pod 对 象 之 间 的 通信 


将 集群 外 部 的 流量 引入 到 Pod 对 象 的 方式 有 受 限 于 Pod 所 在 的 工作 
节点 范围 的 节点 端口 (nodePort) 和 主机 网 络 (hostNetwork) 两 种 ， 以 
及 工作 于 集群 级 别 的 NodePort 或 LoadBalancer 类 型 的 Service 对 象 。 不 
过 ， 即 便 是 四 层 代 理 的 模式 也 要 经 由 两 级 转发 才能 到 达 目 标 Pod 资 源 : 
请 求 流量 首先 到 达 外 部 负载 均衡 器 ， 由 其 调度 至 某 个 工作 和 点 之 上 ， 
而 后 再 由 工作 节点 的 netfilter (kube-proxy) 组 件 上 的 规则 (iptables 或 
ipvs) 调度 至 某 个 目标 Pod 对 象 。 


以 上 4 种 通信 方法 的 具体 应 用 方式 在 前 面 的 章节 中 已 有 详细 描述 ， 
因此 这 里 不 再 给 出 更 进一步 的 说 明 。 


11.1.3 Pod 网 络 的 实现 方式 


每 个 Pod 对 象 内 的 基础 架构 容器 均 使 用 一 个 独立 的 网 络 名 称 空间 ， 
并 共享 给 同一 Pod 内 的 其 他 容器 使 用 。 每 个 名 称 空 间 均 有 其 专用 的 独立 
网 络 协议 栈 及 其 相关 的 网 络 接口 设 备 。 一 个 网 络 接口 仅 能 属于 一 个 网 
络 名 称 空间 ， 于 是 ， 运 行 多 个 Pod 必 然 要 求 使 用 多 个 网 络 名 称 空 间 ， 也 
就 需要 用 到 多 个 网 络 接口 设备 。 不 过 ， 一 个 易于 实现 的 方案 是 使 用 软 
件 实现 的 伪 网 络 接口 及 模拟 线 统 将 其 连接 至 物理 接口 。 伪 网 络 接口 的 
实现 方案 遂 见 的 有 虚拟 网 桥 、 多 路 复 用 及 便 件 交换 三 种 ， 如 图 11-5 所 
RR? 


:虚拟 网 桥 ， 创 建 一 对 虚拟 以 太 网 接口 (veth) ， 一 个 接 入 容器 内 
部 ， 另 一 个 留置 于 根 名 称 空间 内 并 借助 于 Linux 内 核 桥接 功能 或 
OpenVSwitch (OVS) 关联 至 真实 的 物理 接口 。 


.多 路 复 用 : 多 路 复 用 可 以 由 一 个 中 间 网 络 设备 组 成 ， 它 暴露 了 多 
个 虚拟 接口 ， 可 使 用 数据 包 转 发 规则 来 控制 每 个 数据 包 转 到 的 目标 接 
口 。 MACVLAN 为 每 个 虚拟 接口 配置 一 个 MAC 地 址 并 基于 此 地 址 完成 
7 ， 而 IPVLAN 是 基于 IP 地 址 的 并 使 用 单个 MAC， 从 而 使 其 
适合 VM 。 


-人 硬件 交换 : 现今 市 面 上 的 大 多 数 NIC 都 支持 单 根 VO 虚拟 化 (SR- 
IOV) ， 它 是 创建 虚拟 设备 的 一 种 实现 方式 。 每 个 虚拟 设备 自身 均 表现 
为 一 个 独立 的 PCI 设 备 ， 并 有 着 自己 的 VLAN 及 与 硬件 强制 关联 的 
。SR-IOV 提 供 了 接近 硬件 级 别 的 性 能 ， 但 在 公共 云 中 通常 是 不 可 


大 多 数 情 况 下 ， 用 户 希 望 创建 跨越 多 个 L2 或 L3 的 逻辑 网 络 子 网 ， 
这 瓯 要 借助 于 县 加 封装 协议 来 实现 (最 常见 的 是 VXLAN， 它 将 合 加 流 
量 封 装 到 UDP 数据 包 中 ) 。 不 过 ， 由 于 控制 平面 缺乏 标准 化 ，VXLAN 
可 能 会 引入 更 高 的 开销 ， 并 且 来 自 不 同 供应 商 的 多 个 VXLAN 网 络 通常 
无 法 互 操作 。 而 Kubernetes 还 将 大 量 使 用 iptables: 和 NAT 来 拦截 进入 逻 
辑 /虚拟 地 址 的 流量 并 将 其 路 由 到 适当 的 物理 目的 地 。 


Containers Containers Containers 


vetH ) | | 
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图 11-5 ”虚拟 网 桥 、 多 路 复 用 及 硬件 交换 


无 论 上 述 哪 种 方式 应 用 于 容器 环境 中 ， 其 实现 过 程 都 需要 大 量 的 
操作 步骤 。 不 过 ， 目 前 Kubernetes 文 持 使 用 CNI 插 件 来 编排 网 络 ， 以 实 
现 Pod 及 集群 网 络 管理 功能 的 目 动 化 。 每 次 Pod 被 初始 化 或 删除 时 ， 
kubelet 都 会 调用 默认 的 CNI 插 件 创建 一 个 虚拟 设备 接口 附加 到 相关 的 扩 
层 网 络 ， 为 其 设置 中 地址 、 路 由 信息 并 将 其 映射 到 Pod 对 象 的 网 络 名 称 


空间 。 


配置 Pod 的 网 络 时 ，kubelet 首 先 在 默认 的 /etc/cni/net.d/ 目 录 中 查找 
CNI JSON 配 置 文件 ， 接 着 基于 type 属 性 到 /opt/cni/bin/ 中 查找 相关 的 插 
件 二 进 制 文件 ， 如 下 面 示 例 中 的 “portmap”° 随后 ， 由 CNI 搬 件 调用 
IPAM 揪 件 (IP 地 址 管理 ) 来 设置 每 个 接口 的 IP 地 址 ， 如 host-local 或 


dhcp 等 : 


~]$ cat /etc/cni/net.d/10-flannel.conflist 
{ 


"name": "cbrO", 
"plugins": [ 
{ 


"type": "flannel", 
"delegate": { 
"hairpinMode": true, 
"isDefaultGateway": true 
} 
}, 
{ 
"type": "portmap", 
"capabilities": { 
"portMappings": true 


kubelet 基 于 包含 命令 参数 CNIL_ ARGS、CNIL COMMAND 、 
CNI IFNAME、CNI_NETNS、CNI_CONTAINERID、CNI PATH 的 环 
境 变 量 调用 CNI 插 件 ， 并 经 由 stdin 流 式 传输 json.conf 文 件 。 被 调用 的 插 
件 使 用 JSON 格 式 的 文本 信息 进行 啊 应 ， 摘 述 操作 结果 和 状态 。 借 助 于 
插件 框架 ， 有 着 熟练 的 Go 编程 语言 能 力 的 读者 ， 可 以 轻松 开发 出 自己 
的 CNI 插 件 ， 或 者 扩展 现 有 插件 。 


配置 网 络 接 口 时 ，kubelet 将 Pod 对 象 的 名 称 和 名 称 空间 作为 
CNI_ARGS 变 量 的 一 部 分 进行 传递 
(如 “K8S_POD NAMESPACE=default; K8S_POD NAME=myapp- 

6d9f48c5d9-n77qp; ”) 。 它 可 以 定义 每 个 Pod 对 象 或 Pod 网 络 名 称 空间 
的 网 络 配 置 (例如 ， 将 每 个 网 络 名 称 空间 放 在 不 同 的 子 网 中 ) 。 未 来 
的 Kubernetes 版 本 将 网 络 视 为 一 等 的 公民 ， 并 将 网 络 配置 作为 Pod 对 象 
或 名 称 空 间 规 范 的 一 部 分 ， 束 像 内 存 、CPU 和 存储 卷 一 样 。 目 前 ， 可 
以 使 用 注解 (annotations) 来 存储 配置 或 记录 Pod 网 络 数据 /状态 。 


11.1.4 ”CNI 揪 件 及 其 常见 的 实现 


Kubernetes 设 计 了 网 络 模型 ， 但 将 其 实现 交 给 了 网 络 插件 。 于 是 ， 
各 种 解决 方案 不 断 涌 现 。 为 了 规范 及 兼容 各 种 解决 方案 ，CoreOS 和 
Google 联 合 制定 了 CNI (Container Network Interface) 标准 ， 则 在 定义 
容 锅 网 络 模型 规范 。 它 连接 了 两 个 组 件 : 容 事 管理 系统 和 了 网络 插件 。 
它们 之 间 通 过 JSON 格 式 的 文件 进行 通信 ， 以 实现 容 怖 的 网 络 功能 。 有 具 
体 的 工作 均 由 插件 来 实现 ， 包 括 创 建 容 器 netns、 关 联网 络 接口 到 对 应 
的 netns 以 及 为 网 络 接口 分 配 卫 等 。CNI 的 基本 思想 是 : 容器 运行 时 环境 
在 创建 容器 时 ， 先 创建 好 网 络 名 称 空间 (netns) ， 然 后 调用 CNI 插 件 为 
这 个 netns 配 置 网 络 ， 而 后 再 局 动容 髓 内 的 进程 。 


CNI 本 身 只 是 规范 ， 付 诸 生 产 还 需要 有 特定 的 实现 。 目 前 ，CNI 提 
供 的 插件 分 为 三 类 : main、meta 和 ipam。main 一 类 的 插件 主要 在 于 实 
现 某 种 特定 的 网 络 功能 ， 例 如 loopback、bridge、macvlan 和 ipvlan 等 ; 
meta 一 类 的 插件 自 号 并 不 提供 任何 网 络 实现 ， 而 是 用 于 调用 其 他 插 
件 ， 例 如 调用 flannel; ipam 仅 用 于 分 配 卫 地 址 ， 而 不 提供 网 络 实现 。 


CNI 具 有 很 强 的 扩展 性 和 灵活 性 ， 例 如 ， 如 果 用 户 对 某 个 插件 具有 
额外 的 需求 ， 则 可 以 通过 输入 中 的 args 和 环境 变量 CNI_ARGS 进 行 传 
递 ， 然 后 在 插件 中 实现 目 定 义 的 功能 ， 这 大 大 增加 了 它 的 扩展 性 。 男 
外 ，CNI 揪 件 将 main 和 ipam 分 开 ， 赋 了 予 了 用 户 目 由 组 合 它 们 的 机 制 ， 甚 
至 一 个 CNI 插 件 也 可 以 直接 调用 另外 一 个 CNI 插 件 。CNI 目 前 已 经 是 
0 前 推 存 的 网 络 方案 。 销 见 的 CNI 网 络 插件 包含 如 下 这 些 主 
流 的 项 目 。 


:Flannel: 一 个 为 Kubernetes 提 供 琶 加 网 络 的 网 络 插件 ， 它 基于 
Linux TUN/ATAP， 使 用 UDP 封装 IP 报 文 来 创建 到 加 网 络 ， 并 借助 etcd 维 
护 网 络 的 分 配 情况 。 


-Calico: 一 个 基于 BGP 的 三 层 网 络 插 件 ， 并 且 也 支持 网 络 菏 略 来 实 
现 网 络 的 访问 控制 ， 它 在 每 台 机 絮 上 运行 一 个 vRouter， 利 用 Linux 内 核 
来 转发 网 络 数 据 包 ， 并 借助 iptables 实 现 防火 墙 等 功能 。 


-Canal: 由 Flannel 和 Calico 联 合 发 布 的 一 个 统一 网 络 插件 ， 提 供 
CNI 网 络 插件 ， 并 支持 网 络 策略 。 


`Weave Net: Weave Net 是 一 个 多 主机 容器 的 网 络 方案 ， 支 持 去 中 
心 化 的 控制 平面 ， 在 各 个 host 上 的 wRouter 间 建立 Full Mesh 的 TCP 连 
接 ， 并 通过 Gossip 来 同步 控制 信息 。 


数据 平面 上 ，Weave 通 过 UDP 封 儿 实现 L2Overlay， 封 装 文 持 两 种 
模式 ， 一 种 是 运行 在 user space 的 sleeve mode， 另 一 种 是 运行 在 kernal 
space 的 fastpath mode ° 


:Contiv: 思科 开源 的 容器 网 络 方案 ， 主 要 提供 基于 Policy 的 网 络 管 
理 ， 并 与 主流 容器 编排 系统 集成 ，Contiv 最 主要 的 优势 是 直接 提供 了 多 
租户 网 络 ， 并 支持 L2 (VLAN) 、L3 (BGP) 、Overlay (VXLAN) 
等 O 


-OpenContrail: Juniper 推 出 的 开源 网 络 虚 拟 化 平台 ， 其 商业 版 本 为 
Contrail 。 其 主要 由 控制 器 和 vRouter 组 成 ， 控 制 器 提供 虚拟 网 络 的 配 
置 、 探 制 和 分 析 功 能 ，vRouter 则 提供 分 布 式 路 由 ， 负 责 虚 拟 路 由 器 、 
虚拟 网 络 的 建立 及 数据 转发 。 


.Romana: 由 Panic Networks 于 2016 年 释 出 的 开源 项 目 ， 旨 在 借鉴 
(route aggregation) 的 思路 来 解决 车 加 方案 为 网 络 带 来 的 开 


NSX-T: 由 VMware 提供 ， 用 于 定义 敏捷 SDI (Software-Defined 
Infrastructure) 以 构建 云 原 生 应 用 环境 ;其 旨 在 合并 异 构 端点 或 技术 栈 
的 应 用 框架 和 架构 ， 如 vSphere、KVM、 容 器 和 bare metal 等 。 


:kube-router: kube-router 是 Kubernetes 网 络 的 一 体 化 解决 方案 ， 它 
可 取代 kube-proxy 实 现 基 于 ipvs 的 Service， 能 为 Pod 提 供 网 络 ， 支 持 网 络 
策略 以 及 拥有 完美 兼容 BGP 的 高 级 特性 。 


上 述 的 CNI 网 络 插件 在 实现 方式 、 传 输 性 能 、 功 能 特性 等 方面 存在 
着 不 小 的 差别 ， 部 署 时 ， 用 户 需 要 根据 网 络 环境 和 业务 需要 等 来 选择 
合适 的 项 目 。 不 过 ， 就 目前 的 统计 (https://thenewstack.io ) 来 看 ， 
flannel 和 calico 两 个 项 目 是 最 为 流行 的 选择 ， 如 图 11-6 所 示 。 
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图 11-6 ”CNI 网 络 插 件 的 采用 率 统计 情况 〈 含 多 选 ) 


随 着 Kubernetes 的 演进 ， 必 将 涌现 出 越 来 越 多 的 CNI 插 件 ， 它 们 各 
具 特 色 ， 各 有 优 和 劣 。 实 践 中 ， 用 户 根 据 实际 需要 选择 合用 的 方案 即 
可 。 本 章 将 介绍 fannel 和 calico 两 种 主流 的 方案 及 其 部 署 和 应 用 ， 不 
过 ， 男 一 个 非常 值得 关注 的 解决 方案 是 kube-router 。 


11.2 flannel 网 络 插件 


各 Docker 主 机 在 docker0 桥 上 默认 使 用 同一 个 子 网 ， 不 同 节 点 的 容 
句 很 可 能 会 得 到 相同 的 地 址 ， 于 是 跨 世 点 的 容 髓 间 通 信 会 面临 地 址 冲 
突 的 问题 。 另 外 ， 即 使 人 为 地 设 定 多 个 节点 上 的 docker0 桥 使 用 不 同 的 
子 网 ， 其 报 文 也 会 因为 在 网 络 中 缺乏 路 由 信息 而 无 法 准确 送 达 。 事 实 
上 ， 各 种 CNI 揪 件 都 至 少 要 解决 这 两 类 问题 。 


对 于 第 一 个 问题 ，flannel 的 解决 办 法 是 ， 预 留 使 用 一 个 网 络 ， 如 
10.244.0.0/16， 而 后 目 动 为 每 个 节点 的 Docker 容 屡 引 擎 分 配 一 个 子 网 ， 
如 10.244.1.0/24 和 10.244.20/24， 并 将 其 分 配 信息 保存 于 etcd 持 久 存 储 。 
对 于 第 二 个 问题 ，flannel 有 着 多 种 不 同 的 处 理 方法 ， 每 一 种 处 理 方法 也 
可 以 称 为 一 种 网 络 模型 ， 或 者 称 为 flannel 使 用 的 后 端 。 


-VxLAN: Linux 内 核 目 3.7.0 版 本 起 支持 VxLAN，flannel 的 此 种 后 
0 内 核 中 的 VxLAN 模 块 封 北 报 文 ， 这 也 是 flannel 较 为 推荐 
YY 工 Le 


图 11-7 VxLAN 协 议 报 文 


:host-gw: 即 Host GateWay， 它 通过 在 节点 上 创建 到 达 目 标 容器 地 
址 的 路 由 直接 完成 报 文 转发 ， 因 此 这 种 方式 要 求 各 和 点 本 号 必须 在 同 
一 个 二 层 网 络 中 ， 故 该 方式 不 太 适 用 于 较 大 的 网 络 规模 (大 二 层 网 络 
除外 ) 。host-gw 有 着 较 好 的 转发 性 能 ， 且 易于 设 定 ， 推 荐 对 报 文 转发 
性 能 要 求 较 高 的 场景 使 用 。 


-UDP: 使 用 普通 UDP 报 文 封装 完成 隧道 转发 ， 其 性 能 较 前 两 种 方 
式 要 低 很 多 ， 仅 应 该 在 不 文 持 前 两 种 方式 的 环境 中 使 用 。 


flannel 初 创 之 后 的 一 段 时 期 内 ， 不 少 环境 中 的 Linux 发 行 版 的 内 核 
尚且 不 文 持 VxLAN， 而 host-gw 模 式 有 着 略 高 的 网 络 技术 门槛 ， 故 此 大 
多 数 部 署 场景 只 好 使 用 UDP 模式 ，flannel 因 而 不 幸 地 落下 性 能 不 好 的 声 


名 。 不 过 ， 目 前 fannel 的 部 署 默认 后 端 已 经 是 到 加 网 络 模型 VxLAN。 
另外 ， 除 了 这 三 种 后 端 之 外 ，flannel 还 实验 性 地 支持 AliVPC、AWS 
VPC、Alloc 和 GCE 几 种 后 端 。 


11.2.1 ”flannel 的 配置 参数 


为 了 跟 路 各 子 网 分 配 信息 等 ，flannel 使 用 etcd 来 存储 虚拟 IP 和 主机 
IP 之 间 的 映射 ， 各 个 和 点 上 运行 的 flanneld 守 护 进 程 负责 监视 etcd 中 的 
信息 并 完成 报 文 路 由 。 默 认 情 况 下 ，flannel 的 配置 信息 保存 于 etcd 的 键 
名 /coreos.com/network/config 之 下 ， 可 以 使 用 etcd 服 务 的 客户 端 工 具 来 
设 定 或 修改 其 可 用 的 相关 配置 。config 的 值 是 一 个 JSON 格 式 的 字典 数 
据 结 构 ， 它 可 以 使 用 的 键 包 含 以 下 几 个 。 


1) Network: flannel 于 全 局 使 用 的 CIDR 格 式 的 IPv4 网 络 ， 字 符 串 
格式 ， 此 为 必 选 键 ， 余 下 的 均 为 可 选 。 


2) SubnetLen: 将 Network 属 性 指定 的 IPv4 网 络 基于 指定 位 的 掩 码 
切割 为 供 各 节点 使 用 的 子 网 ， 此 网 络 的 掩 码 小 于 24 时 (如 16) ， 其 切 
割 子 网 时 使 用 的 掩 码 默认 为 24 位 。 


3) SubnetMin: 可 用 作 分 配给 节点 使 用 的 起 始 子 网 ， 默 认为 切 分 
完成 后 的 第 一 个 子 网 ， 字 符 串 格式 。 


4) SubnetMax: 可 用 作 分 配给 点 使 用 的 最 大 子 网 ， 默 认为 切 分 
完成 后 最 大 的 一 个 子 网 ， 字 符 香 格式。 


5) Backend: flannel 要 使 用 的 后 端 类 型 ， 以 及 后 端的 相关 配置 ， 
字典 格式 ，VxLAN、hostrgw 和 UDP 后 端 各 有 其 相关 的 参数 。 


例如 下 面 的 配置 示例 中 ， 全 局 网 络 为 “10.244.0.0/16”， 切 分 子 网 时 
用 到 的 掩 码 长 度 为 24， 将 相应 的 子 网 10.244.0.0/24-10.244.255.0/24 分 别 
分 配给 每 一 个 工作 节点 使 用 ， 选 择 VxLAN 作 为 使 用 的 后 端 类 型 ， 并 监 
听 于 8472 端 口 : 


{ 
"Network": "10.244.0.0/16", 
"SubnetLen": 24, 
"Backend": { 
"Type™": "VxLAN", 
"Port": 8472 
} 
} 


以 上 配置 信息 可 直接 由 flannel 保 存 于 etcd 存 储 中 ， 也 可 交 由 
Kubernetes 进 行 存 储 。 上 有 具体 使 用 的 方式 取 雇 于 管理 员 或 部 署 程序 的 默 
认 配 置 。 另 外 ，flanne] 默 认 使 用 VxLAN 后 端 ， 但 VxLAN direct routing 
和 host-gw 却 有 着 更 好 的 性 能 表现 。 


11.2.2 ”VxLAN 后 六 和 direct routing 


VxLAN， 全 称 Virtual extensible Local Area Network (虚拟 可 扩展 局 
域 网 ) ， 是 VLAN 扩 展 方案 草案 ， 采 用 的 是 MAC in UDP 封装 方式 ， 是 
NVo3 (Network Virtualization over Layer3) 中 的 一 种 网 络 虚 拟 化 技术 ， 
如 图 11-8 所 示 。 具 体 实 现 方 式 为 :将 虚拟 网 络 的 数据 帧 添加 到 VxLAN 
首部 后 ， 封 装 在 物理 网 络 的 UDP 报 文中 ， 然 后 以 传统 网 络 的 通信 方式 
传送 该 UDP 报 文 ， 待 其 到 达 目 的 主机 后 ， 云 掉 物 理 网 络 报 文 的 头 部 信 
息 以 及 VxLAN 首 部 ， 然 后 将 报 文 交付 给 目的 终端 ， 如 图 11-9 所 示 的 所 
扑 结构 中 ， 器 和 点 的 Pod 间 通信 即 为 如 此 。 不 过 ， 整 个 过 程 中 通信 双方 
对 物理 网 络 无 所 感知 。 
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图 11-8 ”flannel VxLAN 后 端 
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图 11-9_ flannel VxLAN Direct Routing 后 端 


VxLAN 技 术 的 引入 使 得 逻辑 网 络 拓 扑 和 物理 网 络 拓扑 实现 了 一 定 
程度 的 解 帮 ， 网 络 拓扑 的 配置 对 于 物理 设备 的 配置 的 依赖 程度 有 所 降 
低 ， 配 置 更 灵活 更 方便 。 另 外 ，VLAN 技 术 解决 了 二 层 网 络 广播 域 分 割 
的 问题 ， 提 供 了 多 租户 的 展 好文 持 ， 通 过 VxLAN 进 行 分 割 ， 各 个 租户 
可 以 独立 组 网 、 通 信 。 但 是 ， 为 了 确保 VxLAN 机 制 通信 过 程 的 正确 
性 ， 涉 及 VxLAN 通 信 的 IP 报 文 一 律 不 能 分 片 ， 这 整 要 求 在 物理 网 络 的 
链 路 层 实现 中 必须 提供 足够 大 的 MTU 值 ， 或 者 修改 其 MTU 值 以 保证 
VxLAN 报 文 的 顺利 传输 。 不 过 ， 降 低 默认 MTU 值 ， 以 及 额外 的 首部 开 
销 ， 必 然 会 影响 到 其 报 文 传输 性 能 。 


对 于 Kubernetes 1.7 及 以 后 的 版 本 来 说 ，flannel 项 目 官方 给 出 的 在 线 
配置 方式 清单 中 的 默认 配置 即 为 VxLAN 后 端 ， 它 定义 在 kube-system 名 
称 空间 ConfigMap 资 源 kube-flannel-cfg 中 ， 它 以 10.244.0.0/16 为 Pod 网 络 
地 址 ， 其 配置 内 容 如 下 所 示 : 


net-conf.json: | 


"Network": "10.244.0.0/16", 
"Backend": { 
"Type": "VxLAN" 


另外 ， 它 将 通过 名 为 kube-flannel-ds 的 DaemonSet 控 制 器 资源 ， 在 
每 个 节点 运行 一 个 flannel 相 关 的 Pod 对 象 。DaemonSet 控 制 器 的 Pod 模 板 
中 使 用 “hostNetwork: true” 配 置 每 个 节点 上 的 Pod 资 源 直 接 共享 使 用 刷 
点 的 网 络 名 称 空 间 以 完成 网 络 配置 ， 其 配置 结果 直接 生效 于 万 点 的 根 
网 络 名 称 空 间 。 


传统 的 VxLAN 后 端 使 用 隧道 网 络 转发 琶 加 网 络 的 通信 报 文 会 导致 
不 少 的 流量 开销 ， 于 是 flannel 的 VxLAN 后 端 还 支持 DirectRouting 模 式 ， 
它 通 过 添加 必要 的 路 由 信息 使 用 方 点 的 二 层 网 络 直接 发 送 Pod 的 通信 报 
文 ， 仪 在 跨 IP 网 络 时 ， 才 启用 传统 的 隧道 方式 转发 通信 流量 。 由 于 大 
部 分 场景 中 都 省 去 了 隧道 首部 开销 ， 因 此 DirectRouting 通 信 模 式 的 性 能 
基本 接近 于 直接 使 用 二 层 物 理 网 络 ， 其 架构 模型 如 图 11-9 所 示 。 


将 flannel 项 目 官 方 提供 的 配置 清单 下 载 至 本 地 ， 如 存储 为 Master 斑 
点 上 的 /etc/kubernetes/manifests/kube-flannel.yaml 文 件 ， 而 后 将 其 
ConfigMap 资 源 kube-flannel-cfg 的 data 字 段 中 的 网 络 配置 部 分 修改 为 如 
下 内 容 所 示 ， 并 使 用 “kubectl apply” 命 令 重 新 应 用 于 集群 中 即 可 : 


net-conf .json: | 


"Network": "10.244.0.0/16", 
"Backend": { 
"Type": "VxLAN", 
"Directrouting": true 


} 


配置 完成 后 ， 在 每 个 节点 上 执行 路 由 查看 命令 “ip route show” 可 以 
看 到 其 生成 的 路 由 规则 ， 如 下 所 示 的 结果 是 在 本 书 的 部 署 示例 拓扑 环 
境 中 的 node01 上 生成 的 路 由 信息 ， 其 中 ，10.244.1.0/24 网 络 位 于 本 机 上 
(node01 节 点 ) ， 其 他 的 目标 网 络 则 分 别 位 于 集群 中 的 每 个 主机 之 
上 ， 包 括 masterT 点 : 


10.244.0.0/24 via 172.16.0.70 dev ens33 
10.244.1.0/24 dev cniQ proto kernel scope link src 10.244.1.1 
10.244.2.0/24 via 172.16.0.67 dev ens33 
10.244.3.0/24 via 172.16.0.68 dev ens33 


此 时 ， 在 各 个 集群 节点 上 执行 “iptables-nL”* 命 令 可 以 看 到 ，iptables 
filter 表 的 FORWARD 链 上 由 其 生成 了 如 下 两 条 转发 规则 ， 它 显 式 放行 了 


10.244.0.0/16 网 络 进出 的 所 有 报 文 ， 用 于 确保 由 物理 接口 接收 或 发 送 的 
目标 地 址 或 源 地 址 为 10.244.0.0/16 网 络 的 所 有 报 文 均 能 够 正常 通行 。 这 
些 是 Direct Routing 模式 得 以 实现 的 必要 条 件 : 


target prot opt Source destination 
ACCEPT all -- 10.244.0.0/16 0.0.0.0/0 
ACCEPT all -- 0.0.0.0/0 10.244.0.0/16 


各 个 节操 上 依然 存在 flannel 相 关 接 口 ， 原 因 是 对 于 那些 无 法 通过 直 
接 路 由 到 达 的 主机 上 的 Pod ( 非 同 一 个 二 层 网 络 ) ， 它 依然 是 采用 
VxLAN 的 隧道 转发 机 制 。 按 需 启动 两 个 Pod 测 试 其 通信 ， 并 通过 相关 接 
口 捕 获 通 信 报 文 即 可 分 析 其 结果 。 


fs 注意。 为 了 保证 所 有 pod 均 能 得 到 正确 的 网 络 配置 ， 建 议 在 
创建 pod 资 源 之 前 事先 配置 好 网 络 插件 ， 甚 至 是 事先 了 解 并 根据 自身 业 
务 需 求 测试 完成 中 意 的 目标 网 络 插件， 在 选 型 完成 后 再 部 署 Kubernetes 
集群 ， 而 尽量 避免 中 途 修改 ， 否 则 有 些 pod 资 源 可 能 会 需要 重建 。 


VxLAN Directrouting 后 端 转 发 模式 同时 兼 具 了 VxLAN 后 端 和 host- 
人 既 保 证 了 传输 性 能 ， 又 具备 了 路 二 层 网 络 转发 报 文 的 
能 力 。 


另外 ，VxLAN 后 端的 可 用 配置 参数 除了 Type 之 外 还 有 如 下 几 个 ， 
人 在 用 户 需 要 自 定义 参数 时 可 显 式 给 出 相关 的 配 

.Type: VxLAN， 字 符 串 。 

:VNI: VxLAN 的 标识 符 ， 默 认为 1， 数 值 型 数据 。 


Port: 用 于 发 送 封装 的 报 文 的 UDP 端 口 ， 默 认为 8472;， 数 值 型 数 


.GBP: 全 称 为 Group Based Policy， 配 置 是 否 启用 VxLAN 的 基于 组 
的 策略 机 制 ， 默 认为 否 ;， 布 尔 型 数据 。 


DirectRouting: 证 否 为 同一 个 二 层 网 络 中 的 节点 局 用 直接 路 由 机 
制 ， 类 似 于 host-gw 后 端的 功能 ;此 种 场景 下 ，VxXLAN 仅 用 于 为 那些 不 


在 同一 个 二 层 网 络 中 的 节操 封 泌 并 转发 报 文 ， 布尔 型 数据 。 


11.2.3 ”host-gw 后 端 


host-gw 后 端 通过 添加 必要 的 路 由 信息 使 用 节点 的 二 层 网 络 直 接 发 
送 Pod 的 通信 报 文 ， 其 工作 方式 类 似 于 VxLAN 后 端 中 direct routing 的 功 
0 。 其 工作 模型 示意 图 如 图 11-10 
不 。 


编辑 kube-flannel 配 置 清单 ， 将 ConfigMap 资 源 kube-flannel-cfg 的 
data 字 段 中 网 络 配置 部 分 修改 为 如 下 所 示 的 内 容 ， 并 使 用 “kubectl 
apply” 命 令 重新 应 用 于 集群 中 即 可 配置 flannel 使 用 hostgw 后 端 : 


net-conf .json: | 
{ 


"Network": "10.244.0.0/16", 
"Backend": 
"Type": "host-gw" 


Ca 
localhost 


cnl0 
(bridge) 


图 11-10 ”host-gw 后 端 
配置 完成 后 ， 各 六 点 会 生成 类 似 于 VxLAN direct routing 一 样 的 路 


由 及 iptables 规 则 以 实现 二 层 转 发 Pod 网 络 的 通信 报 文 ， 省 去 了 隧道 转发 
模式 的 额外 开销 。 不 过 ， 对 于 非 同一 个 二 层 网 络 的 报 文 的 转发 ，host- 
gw 则 无 能 为 力 。 


类 似 host-gw 或 VxLAN direct routing 这 种 使 用 静态 路 由 的 方式 来 实 
现 二 层 转发 虽然 较 之 VxLAN 有 着 更 低 的 资源 开销 和 更 好 的 性 能 表现 ， 
人 言 轧 的 规模 也 将 变 得 庞大 且 不 易 


此 外 ，flannel 目 身 并 不 具备 为 Pod 网 络 实施 网 络 全 略 以 实现 其 网 络 
通信 隔离 的 能 力 ， 但 它 能 够 借助 于 Canal 项 目 构建 网 络 策略 功能 。 


11.3 ”网络 蛇 略 


网 络 策略 (Network Policy) 是 用 于 控制 分 组 的 Pod 资 源 彼此 之 间 
如 何 进行 通信 ， 以 及 分 组 的 Pod 资 源 如 何 与 其 他 网 络 端点 进行 通信 的 
规范 。 它 用 于 为 Kubernetes 实 现 更 为 精细 的 流量 控制 ， 实 现 租户 隔离 
机 制 。Kubernetes 使 用 标准 的 资源 对 象 “NetworkPolicy” 供 管理 员 按 需 定 
义 网 络 访问 控制 策略 。 


11.3.1 网 络 案 略 概述 


Kubernetes 的 网 络 蛇 略 功能 由 其 所 使 用 的 网 络 揪 件 实现 ， 因 此 ， 仅 
在 使 用 那些 支持 网 络 策略 功能 的 网 络 插 件 时 才能 够 配置 网 络 策 略 ， 如 
Calico、Canal 及 kube-router 等 。 每 种 解决 方案 各 有 其 特定 的 网 络 策略 实 
现 方 式 ， 它 们 的 实现 或 依赖 于 节点 目 身 的 功能 ， 或 借助 于 Hypervisor 的 
特性 ， 也 可 能 是 网 络 目 身 的 功能 。Calico 的 calico/kube-controllers 即 为 
Calico 项 目 中 用 于 将 用 户 定 义 的 网 络 策略 予以 实现 的 组 件 ， 它 主要 依赖 
于 廊 点 的 iptables 来 实现 访问 控制 功能 ， 如 图 11-11 所 示 。 其 他 支持 网 络 
束 略 的 反 件 也 有 关 似 的 将 网 络 策略 加 以 实现 的 “ 案 上 略 控制 絮 * 或 “ 案 上 略 引 
雍 »。 
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图 11-11 网 络 策略 组 件 构架 


策略 控制 器 用 于 监控 创建 Pod 时 所 生成 的 新 API 端 点， 并 按 需 为 其 
附加 网 络 策略 。 当 发 生 需 要 配置 策略 的 事件 时 ， 侦 听 器 会 监视 到 变 
化 ， 欣 制 右 随即 啊 应 以 进行 接口 配置 和 策略 应 用 。 


Pod 的 网 络 流量 包含 “流入 ”(Ingress) 和 “流出 ”(Egress) 两 种 方 
器 ， 每 种 方 同 的 控制 案 略 则 包含 “允许 "和 “ 茜 止 ”两 种 。 默 认 情 况 下 ， 
Pod 处 于 非 隔离 状态 ， 它 们 的 流量 可 以 自由 来 去 。 一 旦 有 策略 通过 选择 
铬 规则 将 策略 应 用 于 Pod， 那 么 所 有 末 经 明确 允许 的 流量 都 将 被 网 络 策 
格 拒 绝 ， 不 过 ， 其 他 未 被 选择 屡 匹 配 到 的 Pod 不 受 影 响 。 


OO, 意 ”Kubermnetes 自 1.8 版 本 起 才 支 持 Egress 网 络 策略 ， 此 前 
的 ee eh 


11.3.2 ”部 署 Canal 提 供 网 络 策 略 功能 


Canal 代 表 了 针对 云 原生 应 用 程序 的 最 佳 策略 网 络 解决 方案 ， 旧 在 
让 用 户 轻松 地 将 Calico 和 flannel 网 络 部 署 在 一 起 作为 统一 的 网 络 解决 方 
案 ， 将 Calico 的 网 络 策略 执行 与 Calico 和 flannel 琶 加 以 及 非 有 加 网 络 连 
接 选 项 的 丰富 功能 相 结 合 ， 如 图 11-12 所 示 。 
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图 11-12 “Canal 项 目 架 构 组 件 


换 句 话说 ，Calico 项 目 既 能 够 独立 地 为 Kubernetes 集 群 提供 网 络 解 
决 方 案 和 网 络 策略 ， 也 能 与 annel 结 合 在 一 起 ， 由 flannel 提 供 网 络 解决 
方案 ， 而 Calico 此 时 仅 用 于 提供 网 络 策略 ， 这 时 我 们 也 可 以 将 Calico 称 
为 Canal。Calico 将 数据 存储 于 etcd 中 ， 它 文 持 选择 使 用 专用 的 etcd 存 
、 以 Kubernetes API Server 作 为 后 端 存储 ， 这 里 选择 以 第 二 种 

武井 人 了 


O 注意 ” 结合 flannel 工 作 时 ，Calico 提 供 的 默认 配置 清单 中 是 
以 flannel 默 认 使 用 的 10.244.0.0/16 为 Pod 网 络 ， 因 此 ， 请 确保 kube- 
controller-manager 程 序 在 启动 时 通过 --cluster-cidr 选 项 设置 使 用 了 此 网 络 
地 址 ， 并 且 --allocate-node-cidrs 的 值 应 设置 为 true 。 


， 刘 章 之 前 前 ， 要 在 启用 了 RBAC 的 Kubernetes 集 群 中 设置 必要 的 相关 


~]$ kubectl]1 apply -f https://docs.projectcalico.org/v3.2/getting- 
started/kubernetes/ 
installation/hosted/canal/rbac.yaml 


接 下 来 即 可 部 署 Canal 提 供 网 络 策略 : 


~]$ kubectl]1 apply -f https://docs.projectcalico.org/v3.2/getting- 
started/kubernetes/ 
installation/hosted/canal/canal.yaml 


需要 注意 的 是 ，Canal 目 前 直接 使 用 Calico 和 flannel 项 目 ， 代码 本 喘 
并 没有 任何 修改 。 因 此 ， 目 前 的 Canal 只 是 一 种 部 署 模 式 ， 用 于 安装 和 
配置 项 目 ， 从 用 户 和 编排 系统 的 角度 无 颖 地 作为 单一 网 络 解决 方案 协 
同 工 作 。 末 来 ，Canal 项 目 可 能 会 对 Calico 和 flannel 项 目 进 行 代码 更 改 ， 
实现 安装 和 配置 的 进一步 简化 。 


11.3.3 配置 网 络 策 略 


Kubernetes 系 统 中 ， 报 文 流入 和 流出 的 核心 组 件 是 Pod 资 源 ， 因 此 
它们 也 是 网 络 策略 功能 生效 的 主要 目标 ， 因 此 ，NetworkPolicy 对 象 也 
要 使 用 标签 选择 器 事先 选择 出 一 组 Pod 资 源 作为 控制 对 象 。 一 般 来 说 ， 
NetworkPolicy 是 定义 在 一 组 Pod 资 源 上 的 用 于 管控 入 站 流量 的 “Ingress 
规则 ”， 或 者 说 是 管理 出 站 流量 的 “Egress 规则 ”， 也 可 以 是 二 者 组 合 定 
义 ， 而 仅 部 分 生效 还 是 全 部 生效 则 需要 由 spec.policyTypes 了 予以 定义 ， 
如 图 11-13 所 示 。 
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图 11-13 ”网 络 策略 示意 图 


默认 情况 下 ，Pod 对 和 象 既 可 以 接受 来 自任 何 来 源 的 流量 ， 也 能 够 向 
外 部 发 出 期 望 的 所 有 流量 。 而 附加 网 络 策略 机 制 后 ，Pod 对 和 象 会 因 
NetworkPolicy 对 象 的 选 定 而 被 隔离 : 一 旦 名 称 空 间 中 有 任何 
NetworkPolicy 对 象 匹配 了 某 特定 的 Pod 对 象 ， 则 该 Pod 将 拒绝 Network- 
Policy 所 不 允许 的 一 切 连 接 请 求 ， 而 那些 未 被 任何 NetworkPolicy 对 象 匹 
配 到 的 其 他 Pod 对 象 仍 可 接受 所 有 流量 。 因 此 ， 束 特定 的 Pod 集 合 3 
说 ， 入 站 和 出 站 流量 默认 均 处 于 放行 状态 ,除非 有 规则 能 够 明确 匹配 
到 它 。 然 而 ， 一 旦 在 spec.policyTypes 中 指定 了 生效 的 规则 类 型 ， 却 在 
networkpolicy.spec 字 段 中 骸 套 定义 了 没有 任何 规则 的 Ingress 或 Egress 字 
段 时 ， 则 表示 拒绝 相关 方向 上 的 一 切 流量 。 


定义 网 络 策略 时 第 用 到 的 术语 及 说 明 具 体 如 下 。 


:Pod 组 :由 网 络 策略 通过 Pod 选 择 絮 选 定 的 一 组 Pod 的 集合 ， 它 们 
是 规则 生效 的 目标 Pod; 可 由 NetworkPolicy 对 象 通过 macthLabel 或 
matchExpression 选 定 。 


.Egress: 出 站 流量 ， 即 由 特定 的 Pod 组 发 往 其 他 网 络 端点 的 流量 ， 
通常 由 流量 的 目标 网 络 端点 (to) 和 端口 (ports) 来 进行 定义 。 


Ingress: 入 站 流量 ， 即 由 其 他 网 络 疹 点 发 往 特定 Pod 组 的 流量 ， 通 
常 由 流量 发 出 的 源 站 点 (from) 和 流量 的 目标 端口 所 定义 。 


端口 (ports) : TCP 或 UDP 的 端口 号 。 


端点 (to，from) : 流量 目标 和 流量 源 相 关 的 组 件 ， 它 可 以 是 
CIDR 格 式 的 IP 地 址 块 (ipBlock) 、 网 络 名 称 空间 选择 器 
(namespaceSelector) 匹配 的 名 称 空间 ， 或 Pod 选 择 器 (podSelector) 
匹配 的 Pod 组 。 


无 论 是 mngress 还 是 Egress 流 量 ， 与 选 定 的 某 Pod 组 通信 的 另 一 方 都 
可 使 用 “网 络 端点 ?予以 描述 ， 它 通 营 是 某 名 称 空 间 中 的 一 个 或 一 组 Pod 
资源 ， 由 namespaceSelector 选 是 名 称 空间 后 ， 经 由 ipBlock 或 podSelector 
进行 指定 。Pod 集 合 的 选 定 方 式 如 图 11-14 所 示 。 


spec.namespaceSelector 


namespace 


图 11-14 Pod 集 合 的 选 定 方式 


在 mgress 规 则 中 ， 网 络 端点 也 称 为 “ 源 端 点 ”>， 它 们 用 from 字 段 进行 
标识 ， 而 在 Egress 规 则 中 ， 网 络 端点 也 称 为 “目标 端点 ”， 它 们 用 to 字段 
进行 标识 ， 如 图 11-13 所 示 。 不 过 ， 在 未 定义 Ingress 或 Egress 规 则 时 ， 相 
天 方 问 的 流量 均 为 “允许 ”， 即 默认 为 非 隔离 状态 。 而 一 旦 在 
networkpolicy.spec 中 明确 给 出 了 Ingress 或 Egress 字 段 ， 则 它们 的 from 或 
人 白 名 单列 表 ， 而 空 值 意味 着 所 有 端点 ， 即 不 限制 访 
| 梧 。 


11.3.4 管控 入 站 流量 


以 提供 服务 为 主要 目的 的 Pod 对 象 通常 是 请 求 流量 的 目标 对 象 ， 但 
它们 的 服务 未 必 应 该 为 所 有 网 络 问 点 所 访问 ， 这 束 有 必要 对 它们 的 访 
问 许 可 施加 控制 。networkpolicy.spec 中 藤 套 的 Ingress 字 上 段 用 于 定义 入 站 
流量 规则 ， 束 特定 的 Pod 集 合 来 说 ， 入 站 流量 默认 处 于 放行 状态 ， 除 非 
在 所 有 入 站 策略 中 ， 至 少 有 一 条 规则 能 够 明确 匹配 到 它 。Ingress 字 段 
的 值 是 一 个 对 象 列表 ， 它 主要 由 以 下 两 个 字段 组 成 。 


-from<[]Object>: 可 访问 当前 策略 匹配 到 的 Pod 对 象 的 源 地 址 对 象 
列表 ， 多 个 项 目 之 间 的 逻辑 关系 为 “逻辑 或 ”的 关系 ; 若 未 设置 此 字段 
或 其 值 为 裤 ， 则 匹配 一 切 源 地 址 《默认 的 访问 策略 为 不 限制 ) ;如果 
此 字段 至 少 有 一 个 值 ， 那 么 它 将 成 为 放行 的 源 地 址 白 名 单 ， 仅 来 源 于 
此 地 址 列表 中 的 流量 允许 通过 。 


:ports<[]Object>: 当前 策略 匹配 到 的 Pod 集 合 的 可 被 访问 的 端口 对 
象 列表 ， 多 个 项 目 之 间 的 逻辑 天 系 为 “逻辑 或 ”的 天 系 ; 名 未 设置 此 字 
段 或 其 值 为 空 ， 则 匹配 Pod 集 合 上 的 所 有 端口 (默认 的 访问 策略 为 不 限 
制 ) ; 如 果 此 字段 至 少 有 一 个 值 ， 那 么 它 将 成 为 允许 被 访问 的 Pod 端 口 
日 名 单列 表 ， 仅 入 站 流量 的 目标 端口 处 于 此 列表 中 方才 准许 通过 。 


需要 注意 的 是 ，NetworkPolicy 资 源 属 于 名 称 空间 级 别 ， 它 的 有 效 
作用 范围 为 其 所 属 的 名 称 空间 。 


1. 设 置 默 认 的 Ingress 宽 上 略 


必要 时 ， 用 户 可 以 创建 一 个 NetworkPolicy 来 为 名 称 空间 设置 一 
个 “默认 ”的 隅 离 沫 略 ， 该 策略 选择 所 有 的 Pod 对 象 ， 而 后 允许 或 拒绝 任 
何 到 达 这 些 Pod 的 入 站 流量 。 例 如 下 面 的 策略 示例 ， 其 通过 policyTypes 
字段 指明 要 生效 Ingress 类 型 的 规则 ， 但 未 定义 任何 Ingress 字 段 ， 因 此 不 
能 匹配 到 任 一 产 端 点 ， 从 而 拒绝 所 有 入 站 流量 : 


apiVersion: networking.k8s.io/v1 
kind: NetworkPolicy 
metadata: 
name: deny-all-ingress 
spec: 


podselector: {} 
policyTypes: ["Ingress"] 


者 要 将 默认 策略 设置 为 允许 所 有 的 入 站 流量 ， 则 只 需要 显 式 定义 
Ingress 字 段 ， 并 将 其 值 设置 为 至 以 匹配 所 有 源 端 点 即 可 ， 如 下 面 示 例 
中 的 定义 。 不 过 ， 没 有 为 入 站 流量 定义 任何 规则 时 ， 本 身 的 默认 规则 
即 为 允许 访问 ， 因 此 允许 所 有 相关 的 入 站 流量 时 ， 本 喘 无 须 定 义 默 认 
规则 ， 下 面 的 示例 只 是 为 说 明 规则 的 定义 格式 : 


apiVersion: networking.k8s.io/v1 
kind: NetworkPolicy 
metadata: 
name: allow-all-ingress 
spec: 
podselector: {} 
policyTypes: ["Ingress"] 
ingress: 


- {} 


实践 中 ， 通 单 将 献 认 策略 设置 为 拒绝 所 有 的 入 站 流量 ， 而 后 显 式 
放行 允许 的 源 端 总 的 入 站 流量 。 


2. 放 行 特 定 的 入 站 流量 


在 Ingress 规 则 中 髓 套 from 和 ports 字 段 即 可 匹配 特定 的 入 站 流量 ， 仪 
定义 from 字 段 时 将 隐 仿 本 地 Pod 资 源 组 的 所 有 端口 ， 而 仅 定 义 ports 字 段 
时 则 表示 隐 含 所 有 的 源 端 点 。from 和 ports 同 时 定义 时 表示 隐 含 “逻辑 
与 ?关系 ， 它 将 匹配 那些 同时 满足 from 和 ports 的 定义 的 入 站 流量 ， 即 那 
些 来 和 目 from 指 定 的 源 端点 ， 访 问 由 当前 NetworkPolicy 的 podSelector 匹 配 
的 当前 名 称 空 间 的 Pod 资 源 组 上 所 指定 的 ports 的 请 求 ， 如 图 11-15 所 示 。 
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图 11-15 ”Ingress 规 则 的 组 成 方式 


from 字 段 的 值 是 一 个 对 象 列表 ， 它 可 通 套 使 用 ipBlock、 
namespaceSelector 和 podSelector 字 段 来 定义 流量 来 源 ， 此 三 个 字段 匹配 
Pod 资 源 的 方式 各 有 不 同 ， 同 时 使 用 两 个 或 以 上 的 字段 ， 彼 此 之 间 隐 
舍 “ 逻 辑 或 "关系 。 


ipBlock<Object> : 根据 IP 地 址 或 网 络 地 址 块 选择 流量 产 端 点 。 


namespaceSelector<Object> : 基于 集群 级 别 的 标签 挑选 名 称 空 
则 ， 它 将 匹配 由 此 标签 选择 絮 选 出 的 所 有 名 称 空间 内 的 所 有 Pod 对 和 象 ; 
赋予 字段 以 空 值 来 表示 挑选 所 有 的 名 称 空间 ， 即 源 站 点 为 所 有 名 称 空 
间 内 的 所 有 Pod 对 和 象 。 


:podSelector<Object> : 于 NetworkPolicy 所 在 的 当前 名 称 空 间 内 基 
于 标签 选择 需 挑 选 Pod 资 源 ， 赋 子 字 段 以 空 值 来 表示 挑选 当前 名 称 空间 
内 的 所 有 Pod 对 象 。 

:ports 字 上 段 的 值 也 是 一 个 对 象 列表 ， 它 散人 套 port 和 protocol 来 定义 流 
量 的 目标 端口 ， 即 由 NetworkPolicy 匹 配 到 的 当前 名 称 空间 内 的 所 有 Pod 
资源 上 的 端口 。 


:port<string>: 端口 号 或 在 Container 上 定义 的 端口 名 称 ， 未 定义 时 
匹配 所 有 端口 。 


:protocol<string>: 传输 层 协议 的 名 称 ，TCP 或 UDP， 默 认为 TCP。 


下 面 配 置 清 单 中 的 网 络 案 略 示例 定义 了 如 何 开 放 myapp pod 资 源 给 
相应 的 源 站 点 访问 : 


apiVersion: networking.k8s.io/v1 
kind: NetworkPolicy 
metadata: 
name: allow-myapp-ingress 
namespace: default 
spec: 
podSeJlector : 
matchLabels: 
app: myapp 
policyTypes: ["Ingress"] 
ingress: 
- from: 
- ipBlock: 
cidr: 10.244.0.0/16 
except: 
- 10.244.3.0/24 
- podSelector: 
matchLabels: 
app: myapp 
ports: 
- protocol: TCP 
port: 80 


它 将 default 名 称 空间 中 拥有 标签 “app=myapp” 的 Pod 资 源 的 80/TCP 
端口 开放 给 10.244.0.0/16 网 络 内 除 10.244.3.0/24 子 网 中 的 所 有 源 端 点 ， 
以 及 当前 名 称 空间 中 拥有 标签 <app=myapp” 的 所 有 Pod 资 源 访问 ， 其 他 
未 匹配 到 的 源 端 点 的 流量 则 取决 于 其 他 网 络 策略 的 定义 ， 若 没有 任何 
匹配 策略 ， 则 默认 为 允许 访问 。 


11.3.5 ”管控 出 站 流量 


除非 是 仅 于 当前 名 称 空间 中 即 能 完成 所 有 的 目标 功能 ， 否 则 ， 大 
多 数 情 况 下 ， 一 个 名 称 空间 中 的 Pod 资 源 总 是 有 对 外 请 求 的 需求 ， 如 向 
CoreDNS 请 求解 析 名 称 等 。 因 此 ， 通 常 应 该 将 出 站 流量 的 默认 策略 设 
置 为 准许 通过 。 但 如 果 有 必要 对 其 实施 精细 管理 ， 仅 放行 那些 有 对 外 
请 求 需 要 的 Pod 对 象 的 出 站 流量 ， 则 也 可 先 为 名 称 空间 设置 “禁止 所 
有 ”默认 策略 ， 而 后 定义 明确 的 “准许 ” 案 上 略 。 


networkpolicy.spec 中 骸 套 的 Egress 字 段 用 于 定义 入 站 流量 规则 ， 就 
特定 的 Pod 集 合 来 说 ， 出 站 流量 一 样 默认 处 于 放行 状态 ， 除 非 在 所 有 入 
站 策略 中 至 少 有 一 条 规则 能 够 明确 匹配 到 它 。Egress 字 段 的 值 是 一 个 字 
段 列表 ， 它 主要 由 以 下 两 个 字段 组 成 。 


-to<[]Object> : 由 当前 策略 匹配 到 的 Pod 资 源 发 起 的 出 站 流量 的 目 
标 地 址 列表 ， 多 个 项 目 之 间 为 “或 ”(OR) 关系 ; 若 末 定义 或 字段 值 为 
空 则 意味 着 应 用 于 所 有 目标 地 址 (默认 为 不 限制 ) ; 若 明确 给 出 了 主 
机 地 址 列表 ， 则 只 有 目标 地 址 匹配 列表 中 的 主机 地 址 的 出 站 流量 被 放 
人 


.ports<[]Object> : 出 站 流量 的 目标 端口 列表 ， 多 个 端口 之 间 
为 “或 ”(OR) 关系 ; 大 未 定义 或 字段 值 为 空 则 意味 着 应 用 于 所 有 端口 
(默认 为 不 限制 ，;， 若 明确 给 出 了 端口 列表 ， 则 只 有 目标 端口 匹配 列 
表 中 的 端口 的 出 站 流量 被 放行 。 


Egress 规 则 中 ，to 和 ports 字 段 的 值 都 是 对 象 列 表格 式 ， 它 们 可 内 藤 
的 字段 分 别 与 ngress 规 则 中 的 from 和 ports 相 同 ， 区 别 仅 是 作用 到 的 流量 
方 铝 相反 ， 如 图 11-16 所 示 。 


namespace 


jr ~、 ports 
pod Pods 


networkpolicy | Selector Es 


HS ly 


to, ports 


图 11-16 ” ”Egress 字段 的 组 成 方式 
1. 设 置 默 认 Egress 策 略 


类 似 于 使 用 Ingress 的 使 用 方式 ， 用 户 也 可 以 通过 创建 一 个 
NetworkPolicy 对 象 来 为 名 称 空间 设置 一 个 默认 的 隔离 策略 ， 该 策略 选 
择 所 有 的 Pod 对 象 ， 而 后 允许 或 拒绝 由 这 些 Pod 发 出 的 所 有 出 站 流量 。 
例如 下 面 的 策略 示例 ， 它 通过 policyTypes 字 上 段 指 明 要 生效 Egress 类 型 的 
规则 ， 但 未 定义 任何 Egress 字 段 ， 因 此 不 能 匹配 到 任何 目标 端点 ， 从 而 
拒绝 所 有 的 入 站 流量 : 


apiVersion: networking.k8s.io/v1 
kind: NetworkPolicy 
metadata: 
name: deny-all-egress 
spec: 
podselector: {} 
policyTypes: ["Egress"] 


实践 中 ， 需 要 进行 严格 隔离 的 环境 通常 将 默认 策略 设置 为 拒绝 所 
有 出 站 流量 ， 而 后 显 式 放行 允许 到 达 的 目标 端点 的 出 站 流量 。 
2. 放 行 特定 的 出 站 流量 

下 面 的 配置 清单 示例 中 定义 了 一 个 Egress 规 则 ， 它 对 来 目 拥 
有 “app=tomcat” 的 Pod 对 象 的 ， 到 达标 签 为 “app=nginx” 的 Pod 对 和 象 的 80 


端口 ， 以 及 到 达标 签 为 "app=mysqp 的 Pod 对 象 的 3306 端 口 的 流量 给 
放行 : 


apiVersion: networking.k8s.io/v1 
kind: NetworkPolicy 
metadata: 
name: allow-tomcat-egress 
namespace: default 
spec: 
podSselector: 
matchLabels: 
app: tomcat 
policyTypes: ["Egress"] 
egress: 
- to: 
- podSelector: 
matchLabels: 
app: nginx 
ports: 
- protocol: TCP 
port: 80 
- to: 
- podSelector: 
matchLabels: 
app: mysql 
ports: 
- protocol: TCP 
port: 3306 


需要 注意 的 是 ， 此 配置 清单 中 仅 定 义 了 出 站 规则 ， 将 入 站 流量 的 
默认 规则 设置 为 拒绝 所 有 时 ， 还 应 该 为 具有 标签 “app=tomcat” 的 Pod 对 
象 放行 入 站 流量 。 


11.3.6 ”隔离 名 称 空 间 


实践 中 ， 通 常 需要 彼此 隔离 所 有 的 名 称 空间 ， 但 应 该 允许 它们 都 
能 够 与 kube-system 名 称 空间 中 的 Pod 资 源 进行 流量 交换 ， 以 实现 监控 
和 名 称 解 析 等 各 种 管理 功能 。 下 面 的 配置 清单 示例 为 default 名 称 空间 
定义 了 相关 的 规划， 在 出 站 和 入 站 流量 默认 均 为 拒绝 的 情况 下 ， 它 用 
于 放行 名 称 空间 内 部 的 各 Pod 对 象 之 间 的 通信 ， 以 及 与 kube-system 名 
称 空 间 内 各 Pod 间 的 通信 : 


apiVersion: networking,.k8s.io/v1 
kind: NetworkPolicy 
metadata: 
name: namespace-deny-all 
namespace: default 
spec: 
policyTypes: ["Ingress","Egress"] 
podSelector: {} 


apiVersion: networking.k8s.io/v1 
kind: NetworkPolicy 
metadata.: 
name: namespace- 
namespace: default 
spec: 
policyTypes: ["Ingress","Egress"] 
podSelector: {} 
ingress: 
- from: 
- namespaceSelector: 
matchExpressions: 
- key: name 
operator: In 
values: ["default","kube-system"] 
egress: 
- to: 
- namespaceSelector: 
matchExpressions: 
- key: name 
operator: In 
values: ["default","kube-system"] 


需要 注意 的 是 ， 有 些 管理 员 可 能 会 把 一 些 系统 附件 部 署 到 专 有 的 
名 称 空间 中 ， 例 如 把 Prometheus 监 控 系 统 部 署 到 prom 名 称 空间 中 等 ， 
所 有 这 类 的 具有 管理 功能 的 附件 所 在 的 名 称 空间 与 每 一 个 特定 名 称 空 
则 的 出 入 流量 都 应 该 被 放行 。 


11.3.7 ”网 络 蛇 略 应 用 案例 


假设 有 名 为 testing 的 名 称 空间 内 运行 着 一 组 nginx Pod 和 一 组 myapp 
Pod。 要求 实现 如 下 目标 。 


1) myapp Pod 仅 人 允许 来 自 nginx Pod 的 流量 访问 其 80/TCP 端 口 ， 但 
可 以 同 nginx Pod 的 所 有 端口 发 出 出 站 流量 。 


2) nginx Pod 人 允许 任何 源 端 点 对 其 80TCP 端 口 的 访问 ， 并 能 够 向 任 
意 闪 点 发 出 出 站 流量 。 


3) myapp Pod 和 nginx Pod 都 可 与 kube-system 名 称 空 间 的 任意 Pod 进 
人 人 的 通信 ， 以 便于 可 以 使 用 由 kube-dns 提 供 的 名 称 解 析 服 务 


可 


如 图 11-17 所 示 ， 出 站 和 入 站 的 默认 策略 均 为 “禁止 ?。 


namespace testing 
80/tcp 


all 


namespace default 


namespace kube-system 
Cliet ns=kube-system Se 
Pod ( kube-dns DD By 


图 11-17 案例 拓扑 
下 面 是 测试 实现 步骤 。 


第 一 步 : 创建 testing 名 称 空间 ， 并 于 其 内 基于 Deployment 控 制 器 创 
建 用 于 测试 用 的 nginx Pod 和 myapp Pod 各 一 个 ， 创 建 相关 Pod 资 源 时 顺 
便 为 其 创建 与 Deployment 控 制 器 同名 的 Service 资 源 : 


~]$ kubect1l create namespace testing 
~]$ kubectl run nginx --image=nginx:alpine --replicas=1 --namespace=testing \ 


--port 80 --expose --labels app=nginx 
~]$ kubect] run myapp --image=ikubernetes/myapp:vi --replicas=1 \ 
--namespace=testing --port 80 --expose --labels app=myapp 


另外 ， 为 了 便于 在 网 络 蛇 略 规则 中 引用 kube-system 名 称 空间 ， 这 
里 为 其 添加 标签 “ns=kube-system”: 


~]$ kubectl] label namespace kube-system ns=kube-system 


等 相关 资源 创建 完成 后 ， 即 可 通过 与 其 相关 的 Service 资 源 的 名 称 
访问 相关 的 服务 。 例 如 ， 男 外 局 动 一 个 终端 ， 使 用 kubectl 命 令 在 default 
名 称 空 间 中 创建 一 个 用 于 测试 的 临时 交互 式 客户 靖 ; 


~]$ kubectl run cirros-$RANDOM --namespace=default --rm -it --image=cirros -- sh 
/ # 


而 后 基于 此 客户 端 分 别 测试 访问 nginx 和 myapp 的 服务 ， 名 称 空间 
的 默认 网 络 抹 上 略为 准许 访问 ， 接 下 来 确认 其 访问 请 求 可 正常 通过 : 


/ # curl nginx.testing 


/ # curl myapp.testing 
Hello MyApp | Version: vi | <a href="hostname.html">Pod Name</a> 
/ # 


第 二 步 : 定义 网 络 策略 清单 文件 (testing-netpol-denyall.yaml) ， 
将 testing 名 称 空间 的 入 站 及 出 站 的 默认 策略 修改 为 拒绝 访问 ， 并 再 一 次 
进行 访问 测试 : 


apiVersion: networking.k8s.io/v1 
kind: NetworkPolicy 


metadata: 
name: deny-all-traffic 
namespace: testing 
spec: 
podselector: {} 
policyTypes: 
- Ingress 
- Egress 


接 下 来 ， 将 testing-netpol-denyall.yaml 定 义 的 默认 策略 deny-all- 
traffic 予 以 应 用 ， 为 testing 名 称 空 间 设置 默认 的 网 络 策略 ; 


$ kubectl1 apply -f testing-netpol-denyall.yaml 


回 到 第 一 步 创 建 的 交互 式 客户 端 ， 再 次 对 nginx 和 myapp 发 起 访问 
测试 。 为 了 避免 长 时 间 等 待 ， 这 里 为 curl 命 令 添 加 --connect-timeout; 先 项 
为 其 定义 连接 超时 时 长 。 由 下 面 的 命令 可 知 ， 此 时 无 法 再 访问 到 nginx 
和 myapp 的 相关 服务 : 


/ # curl --connect-timeout 2 nginx.testing 
curl: (28) connect() timed out! 

/# curl --connect-timeout 2 myapp.testing 
curl: (28) connect() timed out! 

/ # 


第 三 步 : 定义 流量 放行 规则 配置 清单 nginx-allow-all.yaml， 放 行 
nginx Pod 之 上 80/TCP 端 口 的 所 有 流量 : 


apiVersion: networking.k8s.io/v1 
kind: NetworkPolicy 
metadata: 
name: nginx-allow-all 
namespace: testing 
spec: 
podselector: 
matchLabels: 
app: nginx 
ingress: 
- ports: 
- port: 80 
- from: 
- namespaceSelector: 
matchLabels: 
ns: kube-system 
egress: 
- to: 
policyTypes: 


- Ingress 
- Egress 


2 网 络 策略 应 用 至 集群 中 以 创建 相应 的 网 
纵 束 上 略 : 


~]$ kubectl apply -f nginx-allow-all.yaml 


而 后 表 次 回 到 交互 式 测试 客户 端 发 起 访问 请 求 进行 测试 ， 由 下 面 
的 命令 结果 可 知 ，nginx 已 经 能 够 正常 访问 ， 这 同时 也 意味 着 由 kube- 
system 名 称 空间 中 的 kube-dns 进 行 的 名 称 解 析 服 务 也 为 可 用 状态 : 


/# curl --connect-timeout 2 nginx.testing 


第 四 步 : 定义 网 络 梨 上 略 配 置 清 单 myapp-allow.yaml， 放 行 testing 名 
称 空间 中 来 自 nginx Pod 的 发 往 myapp Pod 的 80/TCP 的 访问 流量 ， 以 及 
myapp Pod 发 往 nginx Pod 的 所 有 流量 。 男 外 ， 人 允许 myapp Pod 与 kube- 
system 和 名称 空 间 的 任何 Pod 进 行 交 互 的 所 有 流量 : 


apiVersion: networking.k8s.io/v1 
kind: NetworkPolicy 
metadata: 
name: myapp-allow 
namespace: testing 
spec: 
podSselector: 
matchLabels: 
app: myapp 
ingress: 
- from: 
- podSelector: 
matchLabels: 
app: nginx 
ports: 
- port: 80 
- from: 
- namespaceSelector: 
matchLabels: 
ns: kube-system 
egress: 
- to: 
- podSelector: 
matchLabels: 


app: nginx 
- to: 
- namespaceSelector: 
matchLabels: 
ns: kube-system 
policyTypes: 
- Ingress 
- Egress 


接 下 来 首先 创建 清单 中 定义 的 网 络 策略 : 


~]$ kubectl apply -f myapp-allow.yaml 
networkpolicy.networking.k8s.io "myapp-allow" configured 


而 后 切换 全 此 前 在 专用 终端 中 创建 的 临 时 使 用 的 交互 式 Pod， 对 
myapp Pod 发 起 访问 请 求 。 由 下 面 的 命令 结果 可 知 ， 其 访问 被 拒 绝 : 


# CUrl --connect-timeout 2 http://myapp.testing 
curl: (28) connect() timed out! 
/ # 


myapp Pod 仅 允许 来 nginx Pod 对 其 80/TCP 端 口 的 访问 ， 于 是 ， 这 
里 进入 testing 名 称 空 间 中 的 是 nginx Pod 的 交互 式 接口 ， 使 用 wget 命 令 对 
myapp Pod 发 起 访问 请 求 ， 如 下 面 的 命令 所 示 : 


~]$ kubectl exec -it nginx-b477df957-jb2nf -n testing -- /bin/sh 
/ # wget http://myapp.testing -0 - -q 

Hello MyApp | Version: vi | <a href="hostname.html">Pod Name</a> 
/ # 


需要 注意 的 是 ， 这 里 的 nginx Pod 经 由 Deployment 控 制 器 创建 ， 
名 称 格式 为 两 级 Hash 字 符 串 ， 读者 执行 测 人 
建 的 标识 符 。 如 果 所 有 测试 均 能 通过 ， 则 表示 网 络 策 略 都 已 经 正常 生 
效 。 此 示例 中 涉及 的 访问 控制 基本 上 能 够 类 比 到 大 多 数 场景 中 策略 设 
置 的 需求 ， 这 里 还 请 读者 细 细 揣摩 其 设置 逻辑 。 


11.4 ”Calico 网 络 插件 


Calico 是 一 个 开源 虚拟 化 网 络 方案 ， 用 于 为 云 原生 应 用 实现 互联 
及 策略 控制 。 与 Flannel 相 比 ，Calico 的 一 个 显著 优势 是 对 网 络 策略 
_\network policy) 的 支持 ， 它 允许 用 户 动态 定义 ACL 规 则 控制 进出 容 
器 的 数据 报 文 ， 实现 为 Pod 间 中 通信 按 需 施加 安全 策略 。 事 实 上 ， 
Calico 可 以 整合 进 大 多 数 主流 的 编排 系统 ， 如 Kubernetes、Apache 
Mesos、 Docker 和 OpenStack 等 。 


Calico 本 刁 是 一 个 三 层 的 虚拟 网 络 方案 它 将 每 个 节点 都 当 作 路 
由 器 (router) ， 将 每 个 节点 的 容器 都 当 作 是 “ 节 斑点 路 由 器 ”的 一 个 终端 
并 为 其 分 } 配 一 个 IP 地 址 ， 各 广 点 路 由 絮 通 过 BGP (Border Gateway 
Protocol) 学 习 生成 路 由 规则 ， 从 而 将 不 同 节 点 上 的 容 需 连接 起 来 。 因 
此 ，Calico 方 案 其 实 是 一 个 纯 三 层 的 解决 方案 ， 通 过 每 个 节点 协议 栈 
的 三 层 (网 络 层 ) 确保 容 锅 之 间 的 连通 性 ， 这 摆脱 了 flannel host-gw 类 
型 的 所 有 市 点 必须 位 于 同一 二 层 网 络 的 限制 ， 从 而 极 大 地 扩展 了 网 络 
规模 和 网 络 边界 。 如 图 11-18 所 示 的 是 Calico 系 统 示意 网。 
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图 11-18 ”Calico 系 统 示意 图 


BGP 是 互联 网 上 一 个 核心 的 去 中 心 化 自治 路 由 协议 ， 它 通过 维护 
IP 路 由 表 或 “前 级 ” 表 来 实现 自治 系统 (AS) 之 间 的 可 达 性 ， 属 于 矢量 
路 由 协议 。 不 过 ， 以 及 Calico 
控制 平面 的 设计 要 求 物 理 网 络 必须 是 二 层 网 络 ， 以 确保 vRouter 间 均 直 
接 可 达 ， 路 由 不 外 Ee 角 将 物理 设备 当 作 下 一 跳 等 原因 ， 为 了 支持 三 层 网 


络 ，Calico 还 推出 了 IP-in-IP 著 加 的 模型 ， 它 也 使 用 Overlay 的 方式 来 传 
输 数 据 。IPIP 的 包头 非常 小 ， 而 且 也 是 内 置 在 内 核 中 ， 因 此 理论 上 它 

的 速度 要 比 VxLAN 快 一 点 ， 但 安全 性 更 差 。Calico 3.x 的 默认 配置 使 用 
的 是 IPIP 类 型 的 传输 方案 而 非 BGP 。 


11.4.1 ”Calico 工 作 特 性 


Calico 利 用 Linux 内 核 在 每 一 个 计算 节点 上 实现 了 一 个 高 效 的 
vRouter (虚拟 路 由 器 ) 进行 报 文 转发 ， 而 每 个 vRouter 都 通过 BGP 负 责 
把 上 自身 所 属 的 节点 上 运行 的 Pod 资 源 的 卫 地 址 信息 基于 蔬 点 的 agent 程 序 

(Felix) 直接 由 vRouter 生 成 路 由 规则 向 整个 Calico 网 络 内 进行 传播 ， 
不 过 ， 尽 管 小 规模 部 署 可 以 直接 互联 ， 但 大 规模 网 络 还 是 建议 使 用 
BGP 路 由 反射 吉 (route reflector) 来 完成 。Felix 也 支持 在 每 个 节点 上 按 
需 生 成 ACL (Access Control List) 从 而 实现 安全 策略 ， 如 隔离 不 同 的 
租户 或 项 目的 网 络 通信 。vRouter 利 用 BGP 通 告 本 节点 上 现 有 的 地 址 分 
配 人 信息， 每 个 vRouter 均 挝 入 BGP 路 由 反射 右 以 实现 控制 平面 扩展 。 


Calico 承 载 的 各 Pod 资 源 直接 通过 vRouter 经 由 基础 网 络 进行 互联 ， 
它 非 徐 加、 无 隧道 、 不 使 用 VRF 表 ， 也 不 依赖 于 NAT， 因 此 每 个 工作 
人 负载 都 可 以 直接 配置 使 用 公 网 IP 接 入 互联 网 ， 当 然 ， 也 可 以 按 需 使 用 
网 络 策略 控制 它 的 网 络 连 通 性 。 


(1) 经 IP 路 由 直 连 


Calico 中 ，Pod 收 发 的 IP 报 文 由 所 在 节点 的 Linux 内 核 路 由 表 负 责 转 
发 ， 并 通过 iptables 规 则 实现 其 安全 功能 。 某 Pod 对 象 发 送 报 文 时 ， 
Calico 应 确保 节点 总 是 作为 下 一 跳 MAC 地 址 返回 ， 不 管 工作 负载 本 身 
可 能 配置 什么 路 由 ， 而 发 往 某 Pod 对 象 的 报 文 ， 其 最 后 一 个 IP 跃 点 就 是 
Pod 所 在 的 节点 ， 也 就 是 说 ， 报 文 的 最 后 一 程 即 由 节点 送 往 目标 Pod 对 
象 ， 如 图 11-19 所 示 。 
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图 11-19 ”经 IP 路 由 直 连 


需 为 某 Pod 对 象 提供 连接 上 时， 系统 上 的 专用 插件 (如 Kubernetes 的 
CNI) 负责 将 需求 通知 给 Calico Agent。 收 到 消息 后 ，Calico Agent 会 为 
每 个 工作 负载 添加 直接 路 径 信息 到 工作 负载 的 TAP 设 备 (如 veth) 。 而 


运行 于 当前 节点 的 BGP 客 户 问 监 控 到 此 类 消 姑 后 会 调用 路 由 reflector 癌 
工作 于 其 他 节点 的 BGP 客 户 端 进 行 通告 。 


(2) 简单 、 高 效 、 易 扩展 


Calico 未 使 用 额外 的 报 文 封 半 和解 封装， 从 而 简化 了 网 络 拓扑 ， 这 
也 是 Calico 高 性 能 、 易 扩展 的 关键 因素 。 毕 竞 ， 小 的 报 文 减少 了 报 文 分 
上 的 可 能 性 ， 而 且 较 少 的 封 委 和 解 封 骤 操 作 也 降低 了 对 CPU 的 占用 。 
此 外 ， 较 少 的 封 疼 也 易于 实现 报 文 分 机 ， 易 于 进行 故障 排查 。 


创建 、 移 动 或 删除 Pod 对 象 时 ， 相 关 路 由 信息 的 通告 速度 也 是 影响 
其 扩展 性 的 一 个 重要 因素 。Calico 出 色 的 扩展 性 缘 于 与 互联 网 架构 设计 
原则 别 无 二 致 的 方式 ， 它 们 都 使 用 了 BGP 作 为 控制 平面 。BGP 以 高 效 
管理 百 万 级 的 路 由 设备 而 闻名 于 世 ，Calico 自 然 可 以 游 思 有 余地 适 配 大 
型 IDC 网 络 规模 。 另 外 ， 由 于 Calico 各 工作 负载 使 用 基 IP 直 接 进 行 互 
联 ， 因 此 它 还 支持 多 个 跨 地 域 的 IDC 之 间 进 行 协同 。 


(3) 较 好 的 安全 性 


原则 上 ，Calico 网 络 允 许 IDC 中 的 任何 工作 负载 与 其 他 任意 目标 进 
行 通信 ， 但 管理 员 或 用 户 却 未 必 期 望 如 此 ， 在 多 租户 IDC 中 隔离 租户 网 
络 儿 乎 是 必然 之 需 。 于 是 ，Calico 操 纵 世 点 上 的 iptables 规 则 以 管控 工作 
负载 的 互联 许可 。 此 种 iptables 规 则 操纵 功能 是 节点 间 的 警戒 哨 ， 负 责 
阻挡 任何 非 许可 流量 ， 并 防止 通过 工作 人 负载 危及 世上 点 目 身 。 


严格 的 域 间 流量 分 隔 : 运行 于 某 个 租户 虚拟 网 络 内 的 应 用 应 严禁 
访问 其 他 租户 的 应 用 ， 这 种 流量 分 隔 是 由 久 经 考验 的 Linux 内 核 中 的 
ACL 子 系统 予以 实现 的 。 


-精细 的 策略 规则 : 实现 了 租户 间隔 离 的 网 络 方案 大 多 并 没有 额外 
实现 细 粒 度 的 安全 策略 ， 而 Calico 通 过 使 用 Linux 内 建 的 ACL 扩 展 来 文 
持 一 众 安全 规则 ， 任 何 可 由 ACL 文 持 的 功能 均 能 通过 Calico 实 现 。 


.简洁 而 不 简单 : Calico 直 接 使 用 IP 网 络 ， 无 须 任 何 地 址 转换 或 隧道 
承载 的 机 制 实现 了 一 个 简洁 的 “WwWYSIWYG” (What You See Is What You 
Get) 网 络 模型 ， 它 可 以 清晰 地 标识 出 每 个 报 文 从 哪儿 来 ， 到 哪儿 去 。 
于 是 ， 管 理 员 可 因此 而 清晰 地 理解 流量 的 来 去 。 


11.4.2 Calico 系 统 架 构 


概括 来 说 ，Calico 主 要 由 Felix、Orchestrator Plugin 、etcd、BIRD 和 
BGP Router Reflector 等 组 件 组 成 ， 其 组 件 染 构 如 图 11-20 所 示 。 


iptables 
2001:db8:1234::1:2 
= 


Routes 


2001:db8:1234::1:4 


2001:db8:1234::1:7 


图 11-20 ”Calico 系 统 组 件 
:Felix: Calico Agent， 运 行 于 每 个 节点 。 


-Orchestrator Plugin: 编排 系统 (如 Kubernetes、OpenStack 等 ) 以 
将 Calico 整 合 进 系统 中 的 插件 ， 例 如 Kubernetes 的 CNI。 


-etcd: 持久 存储 Calico 数 据 的 存储 管理 系统 。 
.BIRD: 用 于 分 发 路 由 信息 的 BGP 客 户 端 。 


:BGP Route Reflector: BGP 路 由 反射 器 ， 可 选 组 件 ， 用 于 较 大 规模 
的 网 络 场景 。 


1.Felix 


Felix 运 行 于 各 节点 的 用 于 支持 端点 (VM 或 Container) 构建 的 守护 
进程 ， 它 负责 生成 路 由 和 ACL， 以 及 其 他 任何 由 节点 用 到 的 信息 ， 从 


而 为 各 端点 构建 连接 机 制 。Felix 在 各 编排 系统 中 主要 负责 以 下 任务 。 


首先 是 接口 管理 (Interface Management) 功能 ， 负 责 为 接口 生成 
必要 的 信息 并 送 往 内 核 ， 以 确保 内 核能 够 正确 处 理 各 端点 的 泊 量 ， 
其 是 要 确保 各 节点 能 够 响应 目标 MAC 为 当前 节点 上 各 工作 负载 的 MAC 
地 址 的 ARP 请 求 ， 以 及 为 其 管理 的 接口 打开 转发 功能 。 男 外 ， 它 还 要 
监控 各 接口 的 变动 以 确保 规则 能 够 得 到 正确 的 应 用 。 


其 次 是 路 由 规划 (Route Programming) 功能 ， 其 负责 为 当前 和 点 
运行 的 各 端点 在 内 核 FIB (Forwarding Information Base) 中 生成 路 由 信 
息 ， 以 保证 到 达 当 前 节点 的 报 文 可 正确 转发 给 端点 。 


再 次 是 ACL 规 划 (ACL Programming) 功能 ， 负 责 在 Linux 内 核 中 
生成 ACL， 用 于 实现 仅 放行 端点 间 的 合法 流量 ， 并 确保 流量 不 能 绕 过 
Calico 的 安全 措施 。 


最 后 是 状态 报告 (State Reporting) 功能 ， 负 责 提 供 网 络 健康 状态 
的 相关 数据 ， 匹 其 是 报告 由 其 管理 的 节点 上 的 错误 和 问题 。 这 些 报告 
数据 会 存储 于 etcd， 供 其 他 组 件 或 网 络 管理 员 使 用 。 


2. 编 排 系统 插件 


编排 系统 插件 (Orchestrator Plugin) 依赖 于 编排 系统 自身 的 实现 ， 
故此 并 不 存在 一 个 固定 的 插件 以 代表 此 组 件 。 编 排 系统 插件 的 主要 功 
能 是 将 Calico 整 合 进 系统 中 ， 并 让 管理 员 和 用 户 能 够 使 用 Calico 的 网 络 
功能 。 它 主要 负责 完成 API 的 转换 和 反馈 输出 。 


编排 系统 通常 有 其 自身 的 网 络 管理 API， 网 络 插件 需要 负责 将 对 这 
些 API 的 调用 转 为 Calico 的 数据 模型 并 存储 于 Calico 的 存储 系统 中 。 如 果 
有 必要 ， 网 络 插件 还 要 将 Calico 系 统 的 信息 反馈 给 编排 系统 ， 如 Felix 的 
存活 状态 ， 网 络 发 生 错误 时 设 定 相应 的 端点 为 故障 等 。 


3.etcd 存 储 系统 


Calico 使 用 etcd 完 成 组 件 间 的 通信 ， 并 以 之 作为 一 个 持久 数据 存储 
系统 。 根 据 编排 系统 的 不 同 ，etcd 所 扮演 角色 的 重要 性 也 因 之 而 异 ， 但 
它 员 军 了 整个 Calico 部 嗜 全 程 ， 并 被 分 为 两 尖 主 机 : 核心 集群 和 代理 

(proxy) 。 在 每 个 运行 着 Felix 或 编排 系统 插件 的 主机 上 都 应 该 运行 一 


个 etcd 代 理 以 降低 etcd 集 群 和 集群 边缘 广 点 的 压力 。 此 模式 中 ， 每 个 运 
行 着 插件 的 节点 都 会 运行 着 etcd 集 群 的 一 个 成 员 节 点 。 


etcd 是 一 个 分 布 式 、 强 一 致 、 具 有 容错 功能 的 存储 系统 ， 这 一 点 有 
助 于 将 Calico 网 络 实现 为 一 个 状态 确切 的 系统 : 要 么 正常 ， 要 么 发 生 故 
障 。 另 外 ， 分 布 式 存储 易于 通过 扩展 应 对 访问 压力 的 提升 ， 而 避免 成 
为 系统 瓶 贷 。 男 外 ，etcd 也 是 Calico 各 组 件 的 通信 总线， 可 用 于 确保 让 
非 etcd 组 件 在 键 空间 (keyspace) 中 监控 某 些 特定 的 键 ， 以 确保 它们 能 
够 看 到 所 做 的 任何 更 改 ， 从 而 使 它们 能 够 及 时 地 响应 这 些 更 改 。 


4.BGP 客 户 端 (BIRD) 


Calico 要 求 在 每 个 运行 着 Felix 的 节点 上 同时 还 要 运行 一 个 BGP 客 户 
端 ， 人 负责 将 Felix 生 成 的 路 由 信息 载 入 内 核 并 通告 到 整个 IDC。 在 Calico 
语 境 中 ， 此 组 件 是 通用 的 BIRD， 因 此 任何 BGP 客 户 端 (如 GoBGP 等 ) 
都 可 以 从 内 核 中 提取 路 由 并 对 其 分 发 对 于 它们 来 说 都 适合 的 角色 。 


BGP 客 户 只 的 核心 功能 就 生路 由 分 发 ， 在 Felix 插 入 路 由 信息 至 内 
核 FIB 中 时 ，BGP 客 户 端 会 捕获 这 些 信息 并 将 其 分 发 至 其 他 市 点 ， 从 而 
确保 了 流量 的 高 效 路 由 。 


5.BGP 路 由 反射 右 (BIRD) 


在 大 规模 的 部 将 场 景 中 ， 简 易 版 的 BGP 和 客户 端 另 于 成 为 性 能 瓶 
贷 ， 因 为 它 要 求 每 个 BGP 客 户 问 部 必须 连接 至 其 同一 网 络 中 的 其 他 所 
有 BGP 客 户 端 以 传递 路 由 信息 ， 一 个 有 着 N 个 下 点 的 部 闭环 境 中 ， 其 存 
在 网 络 连 接 的 数量 为 N 的 二 次 方 ， 随 着 N 值 的 逐渐 增 大 ， 其 连接 复杂 上 度 
会 急剧 上 升 。 因 而 在 较 大 规模 的 部 署 场景 中 ，Calico 应 该 选择 部 车 一 个 
BGP 路 由 反射 厂 ， 它 是 由 BGP 客 户 问 连接 的 中 心 点 ，BGP 的 点 到 点 通信 
也 束 因 此 转化 为 与 中 心 操 的 单 路 通信 模型 ， 如 图 11-18 所 示 。 出 于 元 余 
之 需 ， 生 产 实践 中 应 该 部 署 多 个 BGP 路 由 反射 器 。 对 于 Calico 来 说 ， 
BGP 客 户 端 程序 除了 作为 客户 端 使 用 之 外 ， 还 可 以 配置 成 路 由 反射 
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11.4.3 Calico 部 署 要 点 


安装 Calico 需 要 事先 有 运行 中 的 Kubernetes 1.1 及 以 上 版 本 的 集 
群 ， 如 果 要 用 到 网 络 策略 ， 则 Kubernetes 版 本 要 1.3.0 及 以 上 才 可 以 。 
另外 ， 还 需要 一 个 可 由 Kubernetes 集 群 各 节点 访问 到 的 etcd 集 群 。 虽 然 
可 以 让 Calico 和 Kubernetes 共 同 使 用 同一 个 etcd 集 群 ， 然 则 有 些 场景 
推荐 为 etcd 使 用 专用 集群 ， 如 需要 获得 较 好 的 性 能 时 。 


与 Kubernetes 集 群 进行 整合 时 ，Calico 需 要 提供 三 个 组 件 ， 具 体 如 


:calico/node: Calico 于 Kubernetes 集 群 中 为 每 个 节点 上 运行 的 容器 
提供 Felix Agent 和 BGP 客 户 端 。 


:cni-plugin: CNI 网 络 插件 ， 用 于 整合 Calico 和 kubelet， 发 现 Pod 资 
源 ， 并 将 其 添加 进 Calico 网 络 ， 因 此 ， 每 个 运行 kubelet 的 主机 都 需要 
本 站 六 


:calico/kube-controllers: Calico 网 络 策略 控制 器 。 


Calico 的 安装 有 两 种 方式 ， 一 是 配置 其 独立 运行 于 Kubernetes 集 群 
之 外 ， 但 calico/kube-controllers 依 然 需要 以 Pod 资 源 运行 于 集群 之 上 。 
男 一 种 是 以 插件 方式 配置 Calico 完 全 托管 运行 于 Kubernetes 集 群 之 上 ， 
不 过 此 种 方式 要 求 Kubernetes 版 本 至 少 在 1.4.0 以 上 。 


另外 ，Calico 以 Kubernetes 插 件 方式 部 署 的 实现 方式 有 两 种 ， 一 是 
标准 托管 式 部 署 ， 即 Calico 使 用 专用 的 etcd 存 储 管 理 数据 持久 化 及 组 件 
间 的 通信 。 男 一 个 是 以 Kubernetes API Server 为 Datastore， 调 用 
Kubernetes 的 API 完 成 所 需 的 操作 。 目 3.0 版 本 起 ，Calico 官 方 推荐 使 用 
第 二 种 方式 ， 而 此 前 的 版 本 中 此 种 功能 尚且 不 够 完善 ， 所 推荐 的 则 是 
第 一 种 部 署 方式 。 


再 者 ，Calico 既 可 以 单独 为 Kubernetes 系 统 提供 网 络 服 务 及 网 络 策 
略 ， 也 可 以 与 flannel 整 合 在 一 起 由 flannel 实 现 网 络 服务 而 Calico 仅 提供 
网 络 和 党 略 。 事 实 上 ， 还 有 一 个 本 喘 即 是 将 flannel 或 Calico 合 二 为 一 的 解 
决 方 案 Canal， 不 过 ， 这 已 经 是 男 一 个 独立 的 项 目 。 


需要 注意 的 是 ，Calico 分 配 的 地 址 池 与 Kubernetes 集 群 的 --pod- 
network-cidr 的 值 应 该 保持 一 致 ， 默 认 情 况 下 ，Calico 的 配置 清单 中 使 
用 192.168.0.0/16 作 为 Pod 网 络 。 不 过 ， 如 采用 户 计划 将 Calico 和 flannel 
协同 进行 部 署 ， 则 可 以 在 此 前 已 有 flannel 插 件 的 基础 上 直接 添加 
Calico。11.4.4 节 将 在 讲解 独立 部 署 Calico 的 同时 提供 网 络 服务 及 网 络 
i 协同 flannel 的 部 署 方式 请 读者 参考 官方 文件 中 的 相关 介绍 进行 
区 局 O 〇 


11.4.4” ”部署 Calico 提 供 网 络 服务 和 网 络 策略 


为 了 便于 简化 部 署 环境 及 操作 复杂 度 ， 本 万 的 操作 建立 在 一 个 刚 
由 kubeadm 部 署 完成 的 新 的 Kubernetes 集 群 之 上 ， 部 署 时 为 --pod- 
network-cidr 款 项 指定 了 使 用 192.168.0.0/16 网 络 以 适 配 Calico 的 默认 网 络 
配置 ， 它 还 没有 添加 过 任何 网 络 插件 。Calico 的 部 署 方 式 极其 灵活 ， 这 
里 难以 尽 述 其 所 有 的 实现 方式 ， 仅 以 典型 应 用 场景 对 其 加 以 说 明 。 


Calico 3 目前 仅 文 持 Kubernetes 1.8 及 其 之 后 的 版 本 ， 并 且 它 要 求 使 
用 一 个 能 够 被 各 组 件 访 问 到 的 键 值 存 储 系统 ， 在 Kubernetes 环 境 中 ， 可 
用 的 选择 有 etcd v3 或 Kubernetes API 数 据 存储 。 本 部 署 示 例会 将 
Kubernetes API 作 为 Calico 的 数据 存储 取代 etcd， 这 也 是 在 本 章 写作 时 时 
下 最 新 的 稳定 版 本 Calico 3 版 本 中 推荐 的 配置 。 另 外 ，Calico 3 目前 对 
ee ipvs 模 式 的 支持 尚且 处 于 试用 级 别 ， 因 此 不 建议 读者 在 生产 
环境 用 。 


OO 注意 “不 同 版 本 的 Calico 的 部 署 方式 可 能 不 尽 相同 ， 读 者 需 
具体 情况 参考 官方 文档 来 确定 具体 的 部 署 方案 及 部 署 
东区 

在 启用 了 RBAC 的 Kubemetes 集 群 部 署 Calico 上 时 ， 需 要 先 创建 必要 


的 ClusterRole 和 ClusterRoleBinding 资 源 。Calico 官 方 给 出 了 标准 定义 的 
配置 清单 ， 部 署 时 ， 直 接应 用 在 线 清 单 即 可 ， 如 下 面 的 命令 所 示 : 


~]$ kubect1 apply -f https://docs.projectcalico.org/v3.2/getting- 
started/kubernetes/ 
installation/hosted/rbac-kdd.yaml 


应 用 完成 后 ， 它 会 创建 名 为 calico-node 的 clusterrole 和 
clusterrolebinding， 为 相关 的 Pod 资 源 calico-node 的 ServiceAccount 授 予 必 
要 的 资源 管理 权限 。Kubernetes 集 群 规 模 小 于 50 广 点 上 时， 可 以 类 似 如 下 
命令 部 署 Calico 的 各 相关 组 件 ， 它 们 会 创建 多 个 标准 的 Kubernetes 资 源 
及 数 个 日 定义 的 资源 : 


~]$ kubect1l1 apply -f https:/V/docs,projectcalico.org/Vv3,.2/getting- 
started/kubernetes/ 
installation/hosted/kubernetes-datastore/calico-networking/1.7/calico.yaml 


可 通过 如 下 命令 查看 calico-node 相 关 的 Pod 资 源 于 各 节点 中 的 部 署 
。 得 所 有 Pod 资 源 均 处 于 “Running” 状 态 后 ， 即 可 正常 使 用 其 相关 
J 功能: 


~]$ kubect] get pods -1 k8s-app=calico-node -o wide -n kube-system 


工作 于 IPIP 模 式 的 Calico 会 在 每 个 节点 上 创建 一 个 tunl0 接 口 (TUN 
类 型 虚拟 设备 ) 用 于 封装 三 层 隧 道 报 文 。 节 点 上 创建 的 每 一 个 Pod 资 
源 ， 都 会 由 Calico 自 动 创建 一 对 虚拟 以 太 网 接口 〈TAP 类 型 的 虚拟 设 
备 ) ， 其 中 一 个 附加 于 Pod 的 网 络 名 称 空间 ， 男 一 个 (名 称 以 cali 为 前 
绥 后 跟随 机 字 串 ) 留置 在 节点 的 根 网 络 名 称 空间 ， 并 经 由 tunl0 封 装 或 
解 封 三 层 隧 道 报 文 。Calico IPIP 模 式 如 图 11-21 所 示 。 


ipip tunnel 


中 人 人 (十 
h0 六 - 才 eth0 Toot netns 


Node Node 


图 11-21 Calico IPIP 


部 署 完成 后 ，Calico 会 在 每 个 节点 上 生成 到 达 Kubernetes 集 群 中 每 
个 节点 上 的 Pod 子 网 的 路 由 信息 ， 下 面 所 示 的 路 由 信息 是 部 署 示 例 中 
node01 主 机 上 生成 的 路 由 和 条目， 它们 由 各 市 点 上 的 BIRD 以 点 对 点 的 方 
式 回 网 络 中 的 其 他 节点 进行 通告 并 学 习 其 他 节点 的 通告 而 得 : 


192.168.0.0/24 via 172.16.0.70 dev tun16 proto bird onlink 
blackhole 192.168.1.0/24 proto bird 

192.168.2.0/24 via 172.16.0.67 dev tun16 proto bird onlink 
192.168.3.0/24 via 172.16.0.68 dev tun16 proto bird onlink 


在 每 个 闻 点 上 创建 Pod 资 源 时 ， 由 Calico CNI 插 件 为 其 生成 TAP 设 
备 并 分 配 地 址 后 ， 也 会 在 节点 的 网 络 名 称 空间 中 生成 一 个 新 的 路 由 条 
是 下 所 示 ， 它 指明 了 发 往 本 节点 上 某 特定 Pod IP 的 报 文 应 该 经 
JTAP 接 口 : 


192.168.1.3 dev cali8bbo5ff8b64 scope link 


在 集群 中 部 署 一 些 Pod 资 源 即 可 完成 集群 网 络 连 接 测试 。 假 设 此 时 
在 node01 上 存在 一 个 IP 地 址 为 192.168.1.3 的 Pod A， 以 及 在 node02 上 存 
在 一 个 IP 地 址 为 192.168.2.4 的 Pod B， 通 过 Pod A 的 交互 式 接口 对 PodB 
发 起 ping 请 求 ， 在 node01 的 物理 接口 上 以 root 用 户 的 身份 抓 取 通 信 报 
文 ， 命令 及 截取 的 一 次 通信 的 往返 结果 示例 如 下 : 


~]# tcpdump -i ens33 -nn ip host 172.16.0.66 and host 172.16.0.67 

10:58:03.553589 IP 172.16.0.66 > 172.16.0.67: IP 192.168.1.3 > 192.168.2.4: ICMP 
echo request, id 4096, seq 33, length 64 (ipip-proto-4) 

10:58:03.553883 IP 172.16.0.67 > 172.16.0.66: IP 192.168.2.4 > 192.168.1.3: ICMP 
echo reply, id 4096, seq 33, length 64 (ipip-proto-4) 


命令 结果 显示 ，Pod 间 的 通信 经 由 IPIP 的 三 层 隧 道 转发 ， 外 层 IP 首 
部 中 的 IP 地 址 为 通信 双方 的 节点 IP (172.16.0.66 和 172.16.0.67) ， 内 层 
IP 首 部 中 的 IP 地 址 为 通信 双方 的 Pod IP (192.168.1.3 和 192.168.2.4) 。 
0 IPIP 隧 道 的 开销 较 小 ， 但 其 安全 性 也 


需要 提醒 读者 注意 的 是 ，tunl0 接 口 的 MTU 默 认为 1440， 这 种 设置 
主要 是 为 适 配 Google 的 GCE 环 境 ， 在 非 GCE 的 物理 环境 中 ， 其 最 佳 值 
为 1480。 因 此 ， 对 于 非 GCE 环 境 的 部 署 ， 建 议 将 配置 清单 calico.yaml 下 
载 至 本 地 修改 后 ， 再 将 其 应 用 到 集群 中 。 要 修改 的 内 容 是 DaemonSet 资 
源 calico-node 的 Pod 模 板 ， 将 容器 calico-node 的 环境 变 
量 “FELIX_INPUTMTU” 的 值 修 改 为 1480 即 可 ， 类 似 如 下 所 示 。 图 11-22 
给 出 了 Calico 部 署 于 不 同 网 络 环境 时 不 同 部 署 方式 适用 的 MTU 大 小 。 


Network MTU Calico MTU Calico MTU with IP-in-IP | Caalico MTU with VxLAN (IPv4) 


9000 9000 8980 8950 
1460 (GCE) 1460 1440 1410 
9001 (AWS Jumbo) 9001 8981 8951 


图 11-22 Calico 于 各 网 络 环境 上 适用 的 MTU 


对 于 50 个 方 点 以 上 规模 的 集群 来 说 ， 所 有 Calico 节 点 均 基于 
Kubernetes API 存 取 数 据 会 为 API Server 囊 来 不 小 的 通信 压力 ， 这 就 应 
该 使 用 calico-typha 进 程 将 所 有 Calico 的 通信 集中 起 来 与 API Server 进 行 
统一 交互 。calico-typha 以 Pod 资 源 的 形式 托管 运行 于 Kubernetes 系 统 之 
上 ， 局 用 的 方法 为 下 载 前 面 步骤 中 用 到 的 Calico 的 部 署 清单 文件 至 本 
| | 源 副 本 数量 为 所 期 望 的 值 并 重新 应 用 配 

清单 即 可 : 


apiVersion: apps/vibetal 
kind: Deployment 
metadata: 

name: calico-typha 


spec: 


replicas: <number of replicas> 


每 个 calico-typha Pod 资 源 可 承载 100 到 200 个 Calico 克 点 的 连接 请 
求 ， 最 多 不 要 超过 200 个 。 男 外 ， 整 个 集群 中 的 calico-typha 的 Pod 资 源 
忆 数 尽量 不 要 超过 20 个 。 


11.4.5 客户 病 工 具 calicoctl 


Calico 的 二 进 制 人 直接 操作 Calico 存 储 来 查看 、 
修改 或 配置 Calico 系 统 特性 ， 它 可 以 运行 为 Kubernetes 系 统 之 上 的 Pod 
资源 ， 也 可 直接 以 裸 二 进 制 文件 部 署 于 某 管理 主机 之 上 ， 例 如 ， 
kubectl 所 在 的 某 主 机 以 root 用 户 的 身份 下 载 calicoct 文 件 并 直接 保存 
于 /usr/bin/ 目 隶 中 : 


~]# wget 

https://github.com/projectcalico/calicoctl/releases/download/v3.1.1/calicoctl \ 
-0 /usr/bin/calicoctl 

~]# chmod +x /usr/bin/calicoctl 


calicoctl 通 过 读 写 Calico 的 数据 存储 系统 (datastore) 进行 查看 或 
进行 各 类 管理 操作 ， 通 常 ， 它 需要 提供 认证 信息 经 由 相应 的 数据 存储 
完成 认证 。 使 用 Kubernetes API 数 据 存储 时 ， 需 要 使 用 类 似 kubectl 的 认 
证 信息 完成 认证 。 它 可 以 通过 环境 变量 声明 的 DATASTORE_TYPE 和 
KUBECONFIG 接 入 Kubernetes 集 群 ， 例 如 以 如 下 命令 格式 运行 
calicoctl: 


~]$ DATASTORE_TYPE=kubernetes KUBECONFIG=~/.kube/config calicoctl get nodes 


也 可 以 直接 将 认证 信息 等 保存 于 配 症 文件 中 ， calicoctl 默 认 加 
载 /etc/calico/calicoctl. cfg 配 置 文件 读 取 配 置信 息 " 配置 文件 为 yaml 格 
式 ， 语 法 极其 类 似 于 Kubernetes 的 资源 配置 清单 


apiVersion: projectcalico.org/v3 
kind: CalicoAPIConfig 
metadata: 
spec: 
datastoreType: "kubernetes" 
kubeconfig: "/PATH/TO/ .kube/config" 


将 上 面 示例 配置 中 的 /PATH/TO 路 径 修改 为 相应 的 用 户 家 目录 即 
可 ， 如 /home/ik8s/。 当 然 ， 也 可 以 是 用 户 目 定义 的 其 他 kubeconfig 配 置 
文件 的 存放 路 径 。 


calicoctl 的 通用 语法 格式 为 “calicoctl[options]<command> 
[<args>.…]”， 它 有 春 多 个 子 命 令 ， 用 于 增删 改 查 相应 的 配置 及 状态 信 
忆 守 ° 例 如， 可 使 用 如 下 命令 查看 当前 Calico 部 署 的 相关 亨 点 状态 信 


/UN。 


~]$calicoctl node status 


默认 情况 下 ，Calico 的 BGP 网 络 工作 于 点 对 点 的 网 格 (node-to- 
node mesh) 模型 ， 它 仅 适用 于 较 小 规模 的 集群 环境 。 中 级 集群 环境 应 
该 使 用 全 局 对 等 BGP 模 型 (Global BGP peers) ， 以 在 同一 二 层 网 络 中 
使 用 一 个 或 一 组 BGP 反 射 器 构建 BGP 网 络 环境 。 而 大 型 集群 环境 需要 
使 用 每 节点 对 等 BGP 模 型 (Per-node BGP peers) ， 即 分 布 式 BGP 反 射 
右 模 型 ， 一 个 典型 的 用 法 是 将 每 个 和 点 都 配置 为 目 市 BGP 反 射 右 接 入 
机 染 顶 部 交换 机 上 的 路 由 反射 器 。 


男 外 ， 读 者 也 可 以 通过 如 下 命令 了 解 Calico 当 前 IP 地 址 池 的 相关 设 
定 ， 包 括 其 地 址 范围 ， 是 否 局 用 了 IPIP 模 型 等 : 


~]$ calicoct1 get ipPool -0 yaml 
apiVersion: projectcalico.org/v3 
items: 
- apiVersion: projectcalico.org/v3 
kind: IPPooJ 
metadata: 
spec: 
cidr: 192.168.0.0/16 
ipipMode: Always 
natoutgoing: true 


事实 上 ， 仅 在 那些 不 文 持 用 户 自 定义 BGP 配 置 的 网 络 中 才 需 要 使 
用 IPIP 的 隧道 通信 类 型 。 如 果 读 者 有 一 个 自主 可 探 的 网 络 环境 且 部 署 
规模 较 大 时 ， 可 以 考虑 局 用 BGP 的 通信 类 型 降低 网 络 开销 以 提升 传输 
性 能 ， 并 且 应 该 部 署 BGP 反 射 铝 来 提高 路 由 学 习 效率 。 具 体 的 实现 方 
式 请 参考 Calico 站 点 上 https://docs.projectcalico.org 给 出 的 文档 。 


11.5 本章 小 结 


本 章 详 细 摘 述 了 Kubernetes 的 网 络 模型 、CNI 插 件 体 系 、 主 流 的 
CNI 插 件 flannel 和 Calico， 并 重点 介绍 了 flannel 和 Calico 的 特性 和 应 用 方 
式 ， 具 体 如 下 。 


-Kubernetes 的 网 络 模型 中 包含 容 姨 间 通 信 、Pod 间 通信 、Service 与 
Pod 间 的 通信 ， 以 及 集群 外 部 流量 与 Pod 间 的 通信 四 种 通信 需求。 


:Kubernetes 网 络 模 型 的 实现 通过 CNI 接 口 由 外 部 网 络 插 件 来 实现 ， 
如 flannel、Calico 和 Canal 等 。 


.flannel 文 持 host-gw、VxLAN 和 UDP 等 后 端 ， 默 认为 VXLAN。 


.网 络 策略 能 够 给 为 Pod 间 提供 通信 隔离 机 制 ， 它 文 持 mmgress 和 
Egress 两 种 类 型 时 规则 。 

:Calico 是 另 一 个 流行 的 网 络 插件 ， 它 提供 了 高 性 能 的 适用 于 大 规 
模 网 络 模型 的 虚拟 网 络 。 


第 12 章 ”Pod 资 源 调度 


API Server 接 受 客 户 端 提交 Pod 对 和 象 创 建 请 求 后 的 操作 过 程 中 ， 有 
一 个 重要 的 步骤 是 由 调度 器 程序 (kube-scheduler) 从 当前 集群 中 选择 
一 个 可 用 的 最 佳节 点 来 接收 并 运行 它 ， 通 常 是 默认 的 调度 器 (default- 
scheduler) 负责 执行 此 类 任务 。 对 于 每 个 待 创建 的 Pod 对 象 来 说 ， 调 度 
过 程 通 常 分 为 三 个 阶段 一 预选 、 优 选 和 选 定 三 个 步骤 ， 以 筛选 执行 任 
务 的 最 佳节 点 。 本 章 将 重点 描述 这 三 个 步骤 的 工作 过 程 。 


12.1 Kubernetes 调 度 咒 概述 


Kubernetes 系 统 的 核心 任务 在 于 创建 客户 端 请 求 创建 的 Pod 对 象 并 
确保 其 以 期 望 的 状态 运行 。 创 建 Pod 对 象 时 ， 调 度 器 (scheduler) 负责 
为 每 一 个 未 经 调度 的 Pod 资 源 、 基 于 一 系列 的 规则 集 从 集群 中 挑选 一 个 
合适 的 节点 来 运行 它 ， 因 此 它 也 可 以 称 作 Pod 调 度 器 。 调 度 过 程 中 ， 调 
度 器 不 会 修改 Pod 资 源 ， 而 是 从 中 读 取 数据 ， 并 根据 配置 的 策略 挑选 出 
最 适合 的 万 点 ， 而 后 通过 API 调 用 将 Pod 绑 定 至 挑选 出 的 节点 之 上 以 完 
成 调度 过 程 ， 如 图 12-1 所 示 。 


[| Pod 广 - 
sd Scheduler 一 一 
node list 


—— 


图 12-1 ”Kubernetes 调 度 器 


Kubernetes 内 建 了 适合 绝 大 多 数 场景 中 Pod 资 源 调度 需求 的 默认 调 
度 器 ， 它 支持 同时 使 用 算法 基于 原生 及 可 定制 的 工具 来 选 出 集群 中 最 
适合 运行 当前 Pod 资 源 的 一 个 地 点 ， 其 核心 目标 是 基于 资源 可 用 性 将 各 
Pod 资 源 公平 地 分 布 于 集群 节点 之 上 。 目 前 ,平台 提供 的 默认 调度 器 也 
称 为 “通用 调度 器 ”， 它 通过 三 个 步骤 完成 调度 操作 : 市 点 预选 

(Predicate) 、 节 点 优先 级 排序 (Priority) 及 节点 择优 (Select) ， 如 
图 12-2 所 示 。 


有 ， . node4 | 
node2 (oaed | | , 


| | Predicate | | Priority | ¢f Select | 
> node3 一 一 济 nodel | * node4 


node3 


图 12-2 ”节点 预先 、 优 选 及 选 定 示 意图 


1) 节点 预选 ， 基于 一 系列 预选 规则 〈 如 PodFitsResources 和 
MatchNode-Selector 等 ) 对 每 个 太 点 进行 检查 ， 将 那些 不 符合 条 件 的 太 
点 过 小 挥 从 而 完成 斑点 预选 。 


2) 点 优选 : 对 预选 出 的 节点 进行 优先 级 排序 ， 以 便 选 出 最 适合 
运行 Pod 对 象 的 太太。 


3) 从 优先 级 排序 结果 中 挑 出 优先 级 最 高 的 节点 运行 Pod 对 象 ， 当 
此 类 市 点 多 于 一 个 时 ， 则 从 中 随机 选择 一 个 。 


偶尔 ， 有 些 特殊 的 Pod 资 源 需 要 运行 在 特定 的 节点 之 上 ， 或 者 说 对 
某 类 节点 有 着 特殊 偏好 (如 那些 有 着 SSD、GPU 等 特殊 硬件 的 节点 ) ， 
以 便 更 好 地 匹配 容器 应 用 的 运行 需求 。 男 外 ， 有 的 Pod 资 源 与 其 他 Pod 
资源 存在 着 特定 的 关联 性 ， 它 们 运行 于 同一 节点 以 便 能 够 实现 更 高 效 
的 协同 效果 等 。 此 种 场景 可 通过 组 合 万 点 标签， 以 及 Pod 标 签 或 标签 选 
择 锅 等 来 激活 特定 的 预选 策略 以 完成 高 级 调度 ， 如 
MatchInterPodAffinity、MatchNodeSelector 和 PodToleratesNodeTaints 等 
预先 策略， 它们 用 于 为 用 户 提 供 目 定义 Pod 杀 和 性 或 反 杀 和 性 、 市 点 亲 
和 性 以 及 基于 污点 及 容忍 度 的 调度 机 制 。 


不 过 ， 未 激活 特定 的 预选 策略 时 ，Pod 资 源 对 节点 便 没 有 特殊 侦 
好 ， 相 关 的 预计 策略 无 法 在 市 点 预计 过 程 中 真正 发 挥 作用 。 


12.1.1 ”和 营 用 的 预选 策略 


简单 来 说 ， 预 选 策略 就 是 和 点 过 滤器 ， 例 如 万 点 标签 必须 能 够 匹 
配 到 Pod 资 源 的 标签 选择 器 〈 由 MatchNodeSelector 实 现 的 规则 ) ， 以 及 
Pod 容 器 的 资源 请 求 量 不 能 大 于 节点 上 剩余 的 可 分 配 资源 (由 
PodFitsResources 实 现 的 规则 ) 等 。 执 行 预选 操作 时 ， 调 度 器 将 对 每 个 
下 点 基于 配置 使 用 的 预选 策略 以 特定 次 序 逐 一 龟 查 ， 并 根据 一 票 否决 
制 进 行 节 点 淘汰 。 知 预选 后 不 存在 任何 一 个 满足 条 件 的 节点 ， 则 Pod 被 
置 于 Pending 状 态 ， 直 到 至 少 有 一 个 和 点 可 用 为 止 。 目 前 ，Kubernetes 
1.10 支 持 的 预选 策略 如 图 12-3 所 示 。 


Predicates Ordering 


[ default Predicates 


图 12-3 ”Kubernetes 的 预选 策略 


1) CheckNodeCondition: 检查 是 否 可 以 在 节点 报告 磁盘 、 网 络 不 
可 用 或 未 准备 好 的 情况 下 将 Pod 对 象 调度 于 其 上 。 


) HostName: 若 Pod 对 象 拥有 spec.hostname 属 性 ， 则 检查 节点 名 
称 字 符 串 与 此 属性 值 是 否 匹配 。 


3) PodFitsHostPorts: 若 Pod 容 器 定义 了 ports.hostPort 属 性 ， 则 检查 
其 值 指 定 的 端口 是 否 已 被 节点 上 的 其 他 容器 或 服务 占用 。 在 Kubernetes 
1.0 版 本 之 前 此 预选 策略 名 称 为 PodFitsPorts。 


4) MatchNodeSelector: 若 Pod 对 象 定 义 了 spec.nodeSelector 属 性 ， 
则 检查 节点 标签 是 否 能 匹配 此 属性 值 。 


5) NoDiskConflict: 检查 Pod 对 和 象 请 求 的 存储 卷 在 此 节点 是 否 可 
用 ， 知 不 存在 冲突 则 通过 检查 。 


6) PodFitsResources: 检查 节点 是 否 有 足够 的 资源 (如 CPU、 内 存 
和 GPU 等 ) 满足 Pod 对 象 的 运行 需求 。 节 点 声明 其 资源 可 用 容量 ， 而 
Pod 则 定义 其 资源 需求 ， 于 是 ， 调 度 器 会 判断 节点 是 否 有 足够 的 可 用 资 
源 运行 Pod 对 象 ， 若 无 法 满足 则 返回 失败 原因 (例如 ，CPU 或 内 存 资源 
不 足 等 ) 。 调 度 器 评判 资源 消耗 的 标准 是 节点 已 分 配 的 资源 量 (各 容 
器 的 requests 值 之 和 ) ， 而 非 其 上 各 Pod 对 和 象 已 用 的 资源 量 。 注 意 ， 那 些 
在 注解 中 标记 为 关键 性 (critical) 的 Pod 资 源 不 受 此 预选 策略 控制 。 


7) PodToleratesNodeTaints: 若 Pod 对 象 定义 了 spec.tolerations 属 
性 ， 则 检查 其 值 是 否 能 够 接纳 节点 定义 的 污点 (taints) ， 不 过 ， 它 仅 
关注 具有 NoSchedule 和 NoExecute 两 个 效用 标识 的 污点 。 


8) PodToleratesNodeNoExecuteTaints: 若 Pod 对 象 定 义 了 
spec.tolerations 属 性 ， 则 检查 其 值 是 否 能 够 接纳 太 点 定义 的 NoExecute 类 
型 的 污点 。 


9) CheckNodeLabelPresence: 仅 检 查 和 点 上 指定 的 所 有 标签 的 存 
在 性 ， 要 检查 的 标签 以 及 其 可 否 存 在 取决 于 用 户 的 定义 。 当 集群 中 部 
署 的 太 点 以 regions/zones/racks 的 拓扑 方式 放置 日 基于 此 类 标签 对 其 进 
人 预选 策略 可 以 根据 此 类 标识 将 Pod 资 源 调度 至 此 类 市 点 


10) CheckServiceAffinity: 根据 当前 Pod 对 象 所 属 的 Service 已 有 的 
其 他 Pod 对 象 所 运行 的 节点 进行 调度 ， 其 目的 在 于 将 相同 Service 的 Pod 
对 和 象 放置 在 同一 个 或 同一 类 和 点 上 以 提高 效率 。 此 预选 策略 试图 将 那 
些 在 其 节点 选择 器 中 带 有 特定 标签 的 Pod 资 源 调度 至 拥有 同样 标签 的 节 
点 之 上 上 ， 具 体 的 标签 则 取决 于 用 户 的 定义 。 例 如 ， 若 菜 Service 的 第 一 
个 Pod 有 一 个 节点 选择 器 rack， 而 且 它 被 调度 到 了 标签 为 region=rack 的 
廊 点 ， 则 属于 此 Service 的 所 有 其 他 后 续 的 Pod 对 象 都 将 被 调度 至 具有 相 
同 标签 (region=rack) 的 节点 上 。 若 该 Pod 示 在 其 节点 选择 器 中 指定 标 
签 ， 则 第 一 个 Pod 将 根据 可 用 性 放置 在 任 一 广 点 之 上 ， 而 后 该 Service 的 
所 有 后 续 Pod 对 象 都 将 调度 至 与 该 节点 拥有 相同 标签 值 的 节点 上 。 


11) MaxEBSVolumeCount: 检查 节点 上 已 挂 载 的 EBS 存 储 卷 数量 
是 否 超过 了 设置 的 最 大 值 ， 默 认 值 为 39。 


12) MaxGCEPDVolumeCount: 检查 节点 上 已 挂 载 的 GCE PD 存储 
卷 数 量 是 否 超过 了 设置 的 最 大 值 ， 默 认 值 为 16。 


13) MaxAzureDiskVolumeCount: 检查 节点 上 已 挂 载 的 Azure Disk 
存储 卷 数 量 是 否 超 过 了 设置 的 最 大 值 ， 默 认 值 为 16。 


14) CheckVolumeBinding: 检查 节点 上 已 绑 定 和 未 绑 定 的 PVC 是 否 
能 够 满足 Pod 对 象 的 存储 卷 需求 ， 对 于 已 绑 定 的 PVC， 此 预选 策略 将 检 
查 给 定 的 和 点 是 否 能 够 兼容 相应 的 PV， 而 对 于 未 绑 定 的 PVC， 预 选 党 
略 将 搜索 那些 可 滴 足 PVC 申 请 的 可 用 PV， 并 确保 它 可 与 给 定 的 世上 点 兼 
容 。 


15) NoVolumeZoneConflict， 在 给 定 了 区 域 (zone) 限制 的 前 提 
下 ， 检 查 在 此 节点 上 部 署 Pod 对 象 是 否 存在 存储 卷 冲突 。 某 些 存储 卷 存 
在 区 域 调 度 约 束 ， 于 是 ， 此 类 存储 卷 的 区 域 标签 (zone-labels) 必须 与 
忆 点 上 的 区 域 标签 完全 匹配 方 可 满足 绑 定 条 件 。 


16) CheckNodeMemoryPressure: 若 给 定 的 节点 已 经 报告 了 存在 内 
存 资源 压力 过 大 的 状态 ， 则 检查 当前 Pod 对 象 是 否 可 调度 至 此 节点 之 
上 。 目 前 ， 最 低 优 先 级 的 BestEffort QoS 类 型 的 Pod 资 源 也 不 可 调度 至 此 
类 节点 之 上 ， 因 为 它们 随时 可 能 因 OOM 而 终止 。 


17) CheckNodePIDPressure: 者 给 定 的 世 点 已 经 报告 了 存在 PID 资 
源 压力 过 大 的 状态 ， 则 检查 当前 Pod 对 象 是 否 可 调度 至 此 节点 之 上 。 


| 18) CheckNodeDiskPressure: 若 给 定 的 节点 已 经 报 竺 了 存在 偿 盘 
资源 压力 过 大 的 状态 ， 则 检查 当前 Pod 对 象 是 否 可 调度 至 此 节点 之 上 。 


19) MatchInterPodAffinity: 检查 给 定 节 点 是 否 能 够 满足 Pod 对 象 的 
亲 和 性 或 反 亲 和 性 条 件 ， 以 用 于 实现 Pod 亲 和 性 调度 或 反 亲 和 性 调度 。 


如 上 给 定 的 各 预选 策略 中 ，CheckNodeLabelPresence 利 
CheckServiceAffinity 可 以 接受 特定 的 配置 参数 以 便 在 预选 过 程 中 融合 用 
户 自 定义 的 调度 逻辑 ， 这 类 策略 也 可 称 为 可 配置 策 略 ， 而 余下 那些 不 
可 接受 配置 参数 的 策略 也 统一 称 为 脐 态 策 略 。 田 外 ，NoDiskConflict 、 
PodToleratesNodeNoExecuteTaints 、 CheckNodeLabelPresence 和 
CheckServiceAffinity 没 有 包含 在 默认 的 预选 案 略 中 。 


12.1.2 ”第 用 的 优选 函数 


预选 策略 筛选 并 生成 一 个 节点 列表 后 即 进入 第 二 阶段 的 优选 过 
程 。 在 这 个 过 程 中 ， 调 度 器 向 每 个 通过 预选 的 节点 传递 一 系列 的 优选 
函数 (如 BalancedResourceAllocation 和 TaintTolerationPriority 等 ) 来 计 
算 其 优先 级 分 值 ， 优 先 级 分 值 介 于 0 到 10 之 间 ， 其 中 0 表示 不 适用 ，10 
表示 最 适合 托管 该 Pod 对 象 。Kubernetes 文 持 的 优选 画 数 如 图 12-4 所 
不 ?5 


default Priorities 


图 12-4 ”Kubernetes 文 持 的 优选 画 数 


另外， 调度 器 还 文 持 为 每 个 优选 函数 指定 一 个 简单 的 由 正 数值 表 
示 的 权重 ， 进 行 节 点 优先 级 分 值 的 计算 时 ， 它 首先 将 每 个 优选 函数 的 
计算 得 分 乘 以 其 权重 (大 多 数 优先 级 的 默认 权重 为 1) ， 然 后 将 所 有 优 


选 画 数 的 得 分 相 加 从 而 得 出 节点 的 最 终 优先 级 分 值 。 权 重 属性 赋予 了 
管理 员 定义 优选 画 数 倾向 性 的 能 力 。 下 面 是 每 个 节点 的 最 终 优先 级 得 
分 的 计算 公式 ; 


finalScoreNode= (weight1l*priorityFunc1) + 
(weight2*priorityFunc2) +... 


下 面 是 各 优选 函数 的 相关 说 明 。 


1) LeastRequestedPriority: 由 方 点 空间 资源 与 节点 总 容量 的 比值 
计算 而 来 ， 即 由 CPU 或 内 存 资 源 的 总 容量 减 去 点 上 已 有 Pod 对 象 需求 
的 容量 总 和 ， 再 减 去 当前 要 创建 的 Pod 对 象 的 需求 容量 得 到 的 结果 除 
以 忌 容量 。CPU 和 内 存 具 有 相同 的 权重 ， 资 源 空 几 比 例 越 高 的 节点 得 
分 就 越 高 ， 其 计算 公式 为 : (cpu ( (capacity-sum (requested) ) 
*10/capacity) +memory ( (capacity-sum (requested) ) 

*10/capacity) ) /2° 


2) BalancedResourceAllocation: 以 CPU 和 内 存 资源 占用 率 的 相近 
程序 作为 评估 标准 ， 二 者 越 接近 的 和 点 权重 越 高 。 该 优选 级 函数 不 能 
单独 使 用 ， 它 需要 与 LeastRequestedPriority 组 合 使 用 来 平衡 优化 节点 资 
.0 ， 以 选择 那些 在 部 署 当 前 Pod 资 源 后 系统 资源 更 为 均衡 

» 以 所 O 


3) NodePreferAvoidPodsPriority: 此 优选 级 函数 权限 默认 为 
10000， 它 将 根据 入 点 是 否 设置 了 注解 信 
局 “scheduler.alpha.kubernetes.io/preferAvoidPods” 来 计算 其 优先 级。 计 
算 方 式 是 : 给 定 的 世上 点 无 此 注解 信息 时 ， 其 得 分 为 10 乘 以 权重 10000; 
存在 此 注解 信息 时 ， 对 于 那些 由 ReplicationController 或 ReplicaSet 控 制 
器 管控 的 Pod 对 象 的 得 分 为 0， 其 他 Pod 对 象 会 被 名 略 (得 最 高 分 ) 。 


4) NodeAffinityPriority: 基于 市 点 亲 和 性 调度 偏好 进行 优先 级 评 
舍 ， 它 将 根据 Pod 资 源 中 的 nodeSelector 对 给 定 节 点 进行 匹配 度 检查 ， 
成 功 匹 配 到 的 条 目 越 多 则 节点 得 分 越 高 。 不 过 ， 其 评估 过 程 使 用 首选 
而 非 强制 型 的 *PreferredDuringSchedulingIgnoredDuringExecution” 标 签 
选择 器 。 


5) TaintTolerationPriority: 基于 Pod 资 源 对 节点 的 污点 容忍 调 度 偏 
好 进行 其 优先 级 的 评估 ， 它 将 Pod 对 象 的 tolerations 列 表 与 节点 的 污点 


进行 匹配 度 检 查 ， 成 功 匹 配 的 条 目 越 多 ， 则 市 点 得 分 越 低 。 


6) SelectorSpreadPriority: 首先 查找 与 当前 Pod 对 象 匹 配 的 
Service、ReplicationController、ReplicaSet (RS) 和 StatefulSet， 而 后 
查找 与 这 些 选 择 器 匹配 的 现存 Pod 对 象 及 其 所 在 的 节点 ， 则 运行 此 类 
Pod 对 和 象 越 少 的 证 点 得 分 将 越 高 。 人 简单 来 说 ， 如 其 名 称 所 示 ， 此 优选 
函数 会 尽量 将 同一 标签 选择 喜 匹 配 到 的 Pod 资 源 分 散 到 不 同 的 节点 上 
运行 。 


7) InterPodAffinityPriority: 遍历 Pod 对 象 的 亲 和 性 条 目 ， 并 将 那 
些 能 够 匹配 到 给 定 节 点 的 条 目的 权重 相 加 ， 结 采 值 越 大 的 节点 得 分 越 


0 


8) MostRequestedPriority: 与 优选 画 数 LeastRequestedPriority 的 评 
古 节 点 得 分 的 方法 相似 ， 不 同 的 是 ， 资 源 占用 比例 越 大 的 广 点 ， 其 得 
此 


9) NodeLabelPriority: 根据 节点 是 否 拥 有 特定 的 标签 来 评估 其 得 
分 ， 而 无 论 其 值 为 何 。 需 要 其 存在 时 ， 拥有 相应 标签 的 节操 将 获得 优 
先 级 ， 否 则 ， 不 具有 相应 标签 的 节点 将 获得 优先 级 。 


10) ImageLocalityPriority: 基于 给 定 节 点 上 拥有 的 运行 当前 Pod 对 
象 中 的 容 右 所 依赖 到 的 镜像 文件 来 计算 方 点 得 分 ， 不 具有 Pod 依 赖 到 
的 任何 镜像 文件 的 节点 其 得 分 为 0， 而 拥有 相应 镜像 文件 的 各 节点 中 ， 
所 拥有 的 被 依赖 到 的 镜像 文件 其 体积 之 和 越 大 则 节点 得 分 越 高 。 


Kubernetes 的 默认 调度 絮 以 预选、 优选 、 选 定 机 制 完 成 将 每 个 新 
的 Pod 资 源 绑 定 至 为 其 选 出 的 目标 节点 上 ， 不 过 ， 它 只 是 Pod 对 象 的 默 
认 调 度 器 ， 使 用 中 ， 用 户 还 可 以 自 定 义 调度 器 插件 ， 并 在 定义 Pod 资 
源 配 置 清 单 时 通过 spec.schedulerName 指 定 即 可 使 用 。 


12.2 ”节点 杀 和 调度 


节点 亲 和 性 是 调度 程序 用 来 确定 Pod 对 象 调度 位 置 的 一 组 规则 ， 这 
些 规则 基于 节点 上 的 自 定义 标签 和 Pod 对 象 上 指定 的 标签 选择 器 进行 定 
义 。 节 点 亲 和 性 允许 pod 对 象 定义 针对 一 组 可 以 调度 于 其 上 的 节点 的 亲 
和 性 或 反 亲 和 性 ， 不 过 ， 它 无 法 具体 到 某 个 特定 的 节点 。 例 如 ， 将 Pod 
调度 至 有 着 特殊 CPU 的 节点 或 一 个 可 用 区 域内 的 节点 之 上 。 


定义 太 点 共和 性 规则 时 有 两 种 类 型 的 市 点 亲 和 性 规则 ， 硬 亲 和 性 
(required) 和 软 亲 和 性 (preferred) 。 硬 杀 和 性 实现 的 是 强制 性 规 
则 ， 它 是 Pod 调 度 时 必须 要 满足 的 规划， 而 在 不 存在 满足 规则 的 节点 
时 ，Pod 对 象 会 被 置 为 Pending 状 态 。 而 软 亲 和 性 规则 实现 的 是 一 种 柔性 
调度 限制 ， 它 倾向 于 将 Pod 对 象 运行 于 某 类 特定 的 节点 之 上 ， 而 调度 器 
也 将 尽量 满足 此 需求 ， 但 在 无 法 满足 调度 需求 时 它 将 退 而 求 其 次 地 选 
择 一 个 不 匹配 规则 的 节点 。 


定义 节点 亲 和 规 划 的 关键 点 有 两 个 ， 一 是 为 节点 配置 合乎 需求 的 
标签 ， 另 一 个 是 为 Pod 对 象 定义 合理 的 标签 选择 右 ， 从 而 能 够 基于 标签 
选择 出 符合 期 望 的 目标 方 点 。 不 过 ， 如 
preferredDuringSchedulingIgnoredDuringExecution 和 
requiredDuringSchedulingIgnoredDuringExecution 名 字 中 的 后 半 段 符 串 
IgnoredDuringExecution 隐 含 的 意义 所 指 ， 在 Pod 资 源 基于 节点 亲 和 人 性 规 
则 调度 至 某 节 点 之 后 ， 节 点 标签 发 生 了 改变 而 不 再 符合 此 广 点 亲 和 性 
规则 时 ， 调 度 器 不 会 将 Pod 对 象 从 此 市 点 上 移出 ， 因 为 ， 它 仅 对 新 建 的 
Pod 对 和 象 生 效 。 节 点 亲 和 性 模型 如 图 12-5 所 示 。 


zone=bar 


yaolal-iele) 


nodeAffinity: 
required: 


zone IN ["foo"] Zone IN ["foo". "bar"] 


ssd EXISTS 


图 12-5 ”节点 亲 和 性 


12.2.1 “万 点 便 杀 和 性 


为 Pod 对 象 使 用 nodeSelector 属 性 可 以 基于 市 点 标签 匹配 的 方式 将 
Pod 对 和 象 强制 调度 至 某 一 类 特定 的 节点 之 上 ， 这 一 点 在 第 4 章 中 曾 有 介 
绍 ， 不 过 它 仅 能 基于 简单 的 等 值 关 系 定义 标签 选择 絮 ， _ 而 nodeAffinity 
中 文 持 使 用 matchExpressions 属 性 构建 更 为 复杂 的 标签 选择 机 制 。 例 
如 ， 下 面 的 配置 清单 示例 (required-nodeAffinity-pod.yaml) 中 定义 的 
Pod 对 象 ， 其 使 用 和 点 硬 亲 和 规则 定义 可 将 当前 Pod 对 象 调 度 至 拥有 
Zone 标签 上 且 其 值 为 foo 的 万 点 之 上 : 


apiVersion: v1 
kind: Pod 
metadata: 
name: with-required-nodeaffinity 
spec: 
affinity: 
nodeAffinity: 
requiredDuringSschedulingIgnoredDuringExecution: 
nodeSelectorTerms: 
- matchExpressions: 
- {key: zone, operator: In, values: ["foo"]} 
containers: 
- name: myapp 
image: ikubernetes/myapp:v1 


将 上 面 配 置 清单 中 定义 的 资源 创建 于 集群 之 中 ， 由 其 状态 信息 可 
知 它 处 于 Pending 阶 段 ， 这 和 古 由 于 强制 型 的 万 扣 亲 和 限 制 场景 中 不 存在 
能 够 满足 匹配 条 件 的 万 点 所 致 : 


~]$ kubect1 apply -f required-nodeAffinity-pod.yaml 
pod "with-required-nodeaffinity" created 
~]$ kubect1 get pods with-required-nodeaffinity 


NAME READY STATUS RESTARTS AGE 
with-required-nodeaffinity 0/1 Pending 0 53S 


“kubectl describe” 命 令 显示 的 资源 详细 信息 Events 字 段 中 也 给 出 了 
具体 的 原因 “0/4nodesare available: 4node (s) didn't match node 
selector”， 命 令 及 结果 如 下 所 示 : 


~]$ kubectl describe pods with-required-nodeaffinity 


Events: 
A Reason Age From Message 
Warning FailedSscheduling 6s (x6 over 21s) default-scheduler 0/4 nodes are 
available: 4 node(s) didn't match node selector. 


接 下 来 按 图 12-5 中 的 规划 为 各 节点 设 置 太 点 标签 ， 这 也 十 设 置 廊 
点 杀 和 性 的 前 提 之 一 : 


~]$ kubect1 label node node02.ilinux.io zone=foo 
node "node02.ilinux.io" labeled 
~]$ kubect1 label node node02.ilinux.io zone=foo 
node "node02.ilinux.io" labeled 
~]$ kubect1 label node node03.ilinux.io zone=bar 
node "node03.ilinux.io" labeled 
~]$ kubect1 label node node01.ilinux.io ssd=true 
node "node01.ilinux.io" labeled 
~]$ kubect1 label node node03.ilinux.io ssd=true 
node "node03.ilinux.io" labeled 


设置 完成 后 ，Pod 对 象 with-required-nodeaffinity 的 详细 信息 事件 中 
已 然 出 现成 功 调度 至 node01.ilinux.io 节 点 的 信息 ， 具 体 如 下 所 示 : 


Events: 
Type Reason Age From Message 
Warning FailedScheduling 1m (x15 over 4m) default-scheduler 0/4 nodes 
are available: 4 node(s) didn't match node selector. 
Normal Scheduled 14s default-scheduler Successfully 


assigned with-required-nodeaffinity to node01.ilinux.io 


在 定义 节点 亲 和 人 性 时 ， 
requiredDuringSchedulingIgnoredDuringExecution 字 段 的 值 是 一 个 对 象 列 
表 ， 用 于 定义 节点 便 亲 和 性 ， 它 可 由 一 | 
对 象 组 成 ， 彼 此 间 为 “逻辑 或 "的 关系 ， 进 行 匹 配 度 检查 时 ， 在 多 
nodeSelectorTerm 之 间 只 要 满足 其 中 之 一 即 可 。 rodeseecorTem 
义 贡 点 选择 器 条 目 ， 其 值 为 对 象 列 表 ， 它 可 由 一 个 或 多 
matchExpressions 对 象 定义 的 匹配 规则 组 成 ， 多 个 规则 彼此 之 间 为 < 罗 罗 辑 
与 ”的 关系， 这 就 意味 着 某 节 点 的 标签 需要 完全 匹配 同一 个 
| 有 的 matchExpression 对 象 定 义 的 规则 才 算 成 功 通 

点 选择 器 条 目的 检查 。 而 matchExmpressions 又 可 由 一 到 多 个 标签 
诡 泽 信 组 成 多 个 标签 选择 器 彼此 间 为 “逻辑 与 ?的 关系 。 


下 面 的 资源 配置 清单 示例 (required-nodeAffinity-pod2.yaml) 中 定 
义 了 调度 拥有 两 个 标签 选择 需 的 世上 点 挑选 条 目 ， 两 个 标签 选择 器 彼此 
之 间 为 “逻辑 与 ?的 关系 ， 因 此 ， 满 足 其 条 件 的 节点 为 node01 和 
node03， 如 图 12-5 右 侧 的 Pod 对 象 的 指向 所 示 : 


apiVersion:; v1 


kind: Pod 
metadata: 
name: with-required-nodeaffinity-2 
spec: 
affinity: 
nodeAffinity: 
requiredDuringschedulingIgnoredDuringExecution: 
nodeSelectorTerms: 
- matchExpressions: 
- {key: zone, operator: In, values: ["foo", "bar"]} 
- {key: ssd, operator: Exists, values: []} 
containers: 


- name: myapp 
image: ikubernetes/myapp:vi1 


构建 标签 选择 器 表达 式 中 支持 使 用 操作 符 有 In、NotIn ~ Exists 、 
DoesNotExist、Lt 和 Gt 等 ， 具 体 的 用 法 请 参考 第 4 章 中 关于 标签 选择 器 
的 介绍 。 


另外 ， 调 度 器 在 调度 Pod 资 源 时 ， 节 点 亲 和 人 性 
(MatchNodeSelector) 仅 是 其 节点 预选 策略 中 遵循 的 预选 机 制 之 一 ， 
其 他 配置 使 用 的 预选 策略 依然 正常 参与 节点 预选 过 程 。 例 如 将 上 面 资 

源 配置 清单 示例 中 定义 的 Pod 对 和 象 容器 修改 为 如 下 内 容 并 进行 测试 : 


containers : 
- name: myapp 
image: ikubernetes/myapp:v1 
resources: 
requests: 
cpu: 6 
memory: 20Gi 


在 预选 策略 PodFitsResources 根 据 节 点 资源 可 用 性 进行 节点 预选 的 
过 程 中 ， 它 会 获取 给 定 节 点 的 可 分 配 资源 量 (资源 问题 减 去 已 被 运行 
于 其 上 的 各 Pod 对 象 的 requests 属 性 之 和 ) ， 去 除 那 些 无 法 容纳 新 Pod 对 
象 请 求 的 资源 量 的 节点 。 本 书 试验 环境 中 使 用 的 四 个 节点 (其 中 一 个 
为 Master) 配置 相同 ， 均 为 8 核心 CPU 和 16GB 内 存 ， 它 们 都 无 法 满足 容 
器 myapp 的 需求 ， 因 此 调度 失败 ，Pod 资 源 会 被 置 于 Pending 状 态 。 下 面 


征 将 资源 创建 于 集群 中 ， 而 后 通过 其 详细 信息 获取 到 的 事件 ， 它 表明 
集群 中 仅 有 两 个 节点 符合 节点 选择 能 ， 但 4 个 节点 都 不 具有 充足 的 内 存 
资源 从 而 导致 调度 失败 ; 


Events : 
yps Reason Age From Message 


i FailedScheduling 4s (x2 over 4s) dd scheduler 0/4 nodes are 
available: 2 node(s) didn't match node selector, 4Insufficient memory. 


由 上 壕 操作 过 程 可 知 ， 节 点 硬 亲 和 性 实现 的 功能 与 节点 选择 器 
(nodeSelector) 相似 ， 但 亲 和 性 支持 使 用 匹配 表达 式 来 挑 洗 节点 ， 这 
0 选择 机 制 ， 因 此 可 被 理解 为 新 一 代 的 节点 选 
对 器 。 


12.2.2 ”了 点 软 亲 和 性 


节点 软 亲 和 性 为 让 点 选择 机 制 提 供 了 一 种 柔性 控制 逻辑 ， 被 调度 
的 Pod 对 和 象 不 再 是 “必须 ”而 是 “应 该 ”放置 于 某 些 特定 方 点 之 上 ， 当 条 件 
不 满足 时 ， 它 也 能 够 接受 被 编排 于 其 他 不 符合 条 件 的 廊 点 之 上 。 男 
外 ， 它 还 为 每 种 倾向 性 提供 了 weight 属 性 以 便 用 户 定义 其 优先 级 ， 取 值 
范围 是 1 一 100， 数 字 越 大 优先 级 越 高 。 下 面 一 个 Deployment 资 源 配置 
清单 示例 (deploy-with-preferred-nodeAffinity.yaml]) : 


apiVersion: apps/Vv1I 
kind: Deployment 
metadata: 
name: myapp-deploy-with-node-affinity 
spec: 
replicas: 3 
selector: 
matchLabels: 
app: myapp 
template: 
metadata: 
name: myapp-pod 
labels: 


nodeAffinity: 
preferredDuringSschedulingIgnoredDuringExecution: 
- weight: 60 
preference: 
matchExpressions: 
- {key: zone, operator: In, values: ["foo"]} 
- weight: 30 
preference: 
matchExpressions: 
- {key: ssd, operator: Exists, values: []} 
containers: 
- name: myapp 
image: ikubernetes/myapp:vi 


示例 中 ，Pod 资 源 模板 定义 了 三 点 软 亲 和 性 以 选择 运行 在 拥有 
zone=foo 和 ssd 标 签 (无 论 其 值 为 何 ) 的 节点 之 上 ， 其 中 zone=foo 是 更 为 
重要 的 倾向 性 规则 ， 它 的 权重 为 60， 相 比较 来 说 ，ssd 标 签 就 没有 那么 
关键 ， 它 的 权重 为 30。 这 人 么 一 来 ， 如 果 集 群 中 拥有 足够 多 的 节点 ， 那 
么 它 将 被 此 规则 分 为 四 类 : 同时 满足 拥有 zone=foo 和 ssd 标 签 、 仅 具有 
Zoo=foo 标 签 、 仅 具有 ssd 标 签 ， 以 及 不 具备 此 两 个 标签 ， 如 图 12-6 所 
示 “。 
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weight=60 


zone=baz 


other nodes 


welght=90 welight=30 weight=0 


nodeAffinity: 


preferred: 


zone IN ["foo"], wight=60 
ssd Exists, wight=30 


图 12-6 节点 软 洒 和 1 加 


以 本 书 所 用 的 测试 环境 为 例 ， 它 共有 三 个 节点 (图 12-6 虚 线 内 的 节 
点 ) ， 相 对 于 myapp-deploy-with- 人 0 竹 规则 
来 说 ， 它们 所 拥有 的 倾 回 性 权重 分 别 如 图 12-6 中 标识 的 信息 所 示 。 在 创 

建 需要 3 个 Pod 对 象 的 副本 时 ， 它 们 会 不 会 补 创 建 于 同一 节点 node01 之 
上 ? 下 面 来 验证 其 运行 效果 : 


~]$ kubect] create -f deploy-with-preferred-nodeAffinity,.yaml 

deployment.apps "myapp-deploy-with-node-affinity" created 

~]$ kubect] get pods -1 app=myapp -0 wide 

NAME READY STATUS RESTARTS AGE IP NODE 
myapp-deploy-...-8qrv7 1/1 Running 0 12s 10.244.2.131 node02.ilinux.io 
myapp-deploy-...-j5d7j 1/1 Running 0 12s 10.244.1.20 node01.ilinux.io 
myapp-deploy-...-twdsr 1/1 Running 0 12s 10.244.3.149 node03.ilinux.io 


结果 显示 ， 三 个 Pod 对 象 被 分 散 运 行 于 集群 中 的 三 个 节点 之 上 ， 而 
1 Tod 之 所 以 如 此 ， 是 因为 使 用 了 廊 点 软 杀 和 性 
~ 所 有 节点 均 能 够 通过 调度 句 上 MatchNodeSelector 预 选 策 
略 的 往 因此 ， 可 用 节点 取决 于 其 他 预选 策略 的 入 选 结果 。 在 膏 
阶 和 的 代 选 过 程 中 ， 除了 NodeAffinityPriority 优 选 男 数 之 外 ， 还 有 其 他 
几 个 优选 画 数 参 与 优先 级 评估 ， 尤 其 是 SelectorSpreadPriority， 它 会 将 
同一 个 ReplicaSet 控 制 吉 管控 的 所 有 Pod 对 象 分 散 到 不 同 的 和 点 上 运行 
以 抵御 节点 故障 带 来 的 风险 。 不 过 ， 这 种 太 点 杀 和 性 的 权重 依然 在 发 
挥 作用 ， 如 果 把 副本 数量 扩展 至 越过 节点 数 很 多 (如 15 个 ) ， 那 么 它 


们 将 被 调度 器 以 接近 市 点 亲 和 性 权重 比值 (90: 60: 30) 的 方式 分 置 
于 相关 的 太太 之 上 ， 读 者 可 目 行 验证 其 效 末 。 


12.3 ”Pod 资 源 亲 和 调度 


出 于 高 效 通 信 的 需求 ， 偶 尔 需要 把 一 些 Pod 对 象 组 织 在 相近 的 位 
置 〈 同 一 节点 、 机 架 、 区 域 或 地 区 等 ) ， 如 某 业 务 的 前 端 Pod 和 后 端 
Pod 等 ， 此 时 可 以 将 这 些 Pod 对 象 间 的 关系 称 为 亲 和 性 。 偶 尔 ， 出 于 安 
全 或 分 布 式 等 原因 也 有 可 能 需要 将 一 些 Pod 对 象 在 其 运行 的 位 置 上 隔 
离开 来 ， 如 在 每 个 区 域 运 行 一 个 应 用 代理 Pod 对 象 等 ， 此 时 可 把 这 些 
Pod 对 象 间 的 关系 称 为 反 亲 和 性 (anti-affinity) 


当然 ， 也 可 以 通过 节点 亲 和 性 来 定义 Pod 对 象 间 的 亲 和 或 反 亲 和 
特性 ， 但 用 户 必 须 为 此 明确 指定 Pod 可 运行 的 节点 标签 ， 显 然 这 并 非 
较 优 的 选择 。 较 理想 的 实现 方式 是 ， 人 允许 调度 器 把 第 一 个 Pod 放 置 于 
任何 位 置 ， 而 后 与 其 有 亲 和 或 反 亲 和 关系 的 Pod 据 此 动态 完成 位 置 编 
排 ， 这 就 是 Pod 亲 和 性 调度 和 反 亲 和 人 性 调度 的 功用 。Pod 的 亲 和 性 定义 
也 存在 “ 硬 ” required) 亲 和 性 和 “ 软 ”(preferred) 亲 和 人 性 的 区 别 ， 它 
们 表示 的 约束 意义 同 节点 亲 和 性 相似 。 


Kubernetes 调 度 器 通过 内 建 的 MatchInterPodAffinity 预 选 策 略为 这 
种 调度 方式 完成 节点 预选 ， 并 基于 InterPodAffinityPriority 优 选 范 数 进 
行 各 下 点 的 优选 级 评估 。 


12.3.1 位置 拓扑 


Pod 杀 和 性 调度 需要 各 相关 的 Pod 对 象 运行 于 “同一 位 置 "， 而 反 亲 
和 性 调度 则 要 求 它们 不 能 运行 于 “同一 位 置 "。 何谓 同一 位 置 ? 事实 
上 ， 它 们 取决 于 节点 的 位 置 拓扑 ， 拓 扑 的 方式 不 同 ， 对 于 如 图 12-7 中 
所 示 的 Pod-A 和 Pod-B 和 是否 在 同一 位 置 的 判定 结果 也 可 能 有 所 不 同 。 


如 果 以 基于 各 节点 的 kubernetes.io/hostname 标 签 作为 评判 标准 ， 那 
么 很 显然 ,“ 同 一 位 置 意 味 着 同一 个 节点 ， 不 同 节 总 即 不 同 的 位 置 ， 
如 图 12-8 所 示 。 


server4 serverl 


SelVerT3 server2 


图 12-7 ”Pod 资源 与 位 置 拓扑 


Kubernetes.I1o 人 hostname=selIveI4 | Kubernetes.10/hostname=server! 


Kubernetes.i0/hostname=server3 | Kubernetes.1i0/hostname=server2 


图 12-8 ”基于 节点 的 位 置 拓扑 


而 如 果 是 基于 如 图 12-9 所 划分 的 故障 转移 域 来 进行 评判 ， 那 么 
server1 和 server4 属 于 同一 位 置 ， 而 server2 和 server3 属 于 另 一 个 意义 上 
的 同一 位 置 。 


failure-domain.beta.kubernetes.10/zone=foo 


failure-domain.beta.kubernetes.10/zone=bar 


图 12-9 ”基于 故障 转移 域 的 位 置 拓扑 


故此 ， 在 定义 Pod 对 象 的 杀 和 性 与 反 杀 和 性 时 ， 和 需要 借助 于 标签 
选择 硕 来 选择 被 依赖 的 Pod 对 象 ， 并 根据 选 出 的 Pod 对 象 所 在 节点 的 标 
签 来 判定 “同一 位 置 ” 的 具体 意义 。 


12.3.2 ”Pod 硬 亲 和 调 度 


Pod 强 制约 束 的 亲 和 人 性 调度 也 使 用 
requiredDuringSchedulingIgnoredDuringExecution 属 性 进行 定义 。Pod 亲 
和 性 用 于 描述 一 个 Pod 对 和 象 与 具有 某 特 征 的 现存 Pod 对 象 运行 位 置 的 依 
赖 天 系 ， 因 此 ， 测 斌 使 用 Pod 亲 和 性 约束 ， 需 要 事先 存在 被 依赖 的 Pod 
对 象 ， 它 们 具有 特别 的 识别 标签 。 下 面 创 建 一 个 有 着 标 
签 “app=tomcat” 的 Tahomaal 源 部 署 一 个 Pod 对 象 : 


~]$kubect1l run tomcat-1 app=tomcat--image tomcat: alpine 


下 面 的 资源 配置 清单 (required-podAffinity-pod1. I 中 定义 了 
一 个 Pod 对 象 ， 它 通过 labelSelector 定 义 的 标签 选择 器 挑选 感 兴趣 的 现存 
Pod 对 象 ， 而 后 根据 挑选 出 的 Pod 对 象 所 在 节点 的 标 
签 “kubernetes.io/hostname” 来 判断 同一 位 置 的 具体 含 含义 ， 并 将 当前 Pod 
对 象 调度 至 这 一 位 置 的 某 节点 之 上 : 


apiVersion: v1 
kind: Pod 
metadata: 
name: with-pod-affinity-1 
spec: 
affinity: 
podAffinity: 
requiredDuringschedulingIgnoredDuringExecution: 
- labelSelector: 
matchExpressions: 
- {key: app, operator: In, values: ["tomcat"]} 
topologyKey: kubernetes.io/hostname 
containers: 
- name: myapp 
image: ikubernetes/myapp:v1 


事实 上 ，kubernetes.io/hostname 标 签 是 Kubernetes 集 群 廊 点 的 内 建 
标签 ， 它 的 值 为 当前 厄 点 的 三 点 主机 名 称 标识 ， 对 于 各 个 记 点 来 说 ， 
各 有 不 同 。 因 此 ， 新 建 的 Pod 对 象 将 被 部 署 至 被 依赖 的 Pod 对 象 的 同一 
节点 之 上 ，requiredDuringSchedulingIgnoredDuringExecution 表 示 这 种 亲 
和 性 为 强制 约束 。 


~]$ kubect] apply -f required-podAffinity-pod1i.yaml 
~]$ kubectl get pods -o wide 


NAME READY STATUS RESTARTS AGE IP NODE 
tomcat-69f99cdf9d-6hvb5 1/1 Running 0 6m 10.244.3.152 
node03.ilinux.io 

with-pod-affinity-1 1/1 Running 0 4s 10.244.3.154 


node03.ilinux.io 


基于 单一 节点 的 Pod 亲 和 性 只 在 极 个 别 的 情况 下 才 有 可 能 会 用 到 ， 
较为 常用 的 通常 是 基于 同一 地 区 (region) 、 区 域 (zone) 或 机 架 
(rack) 的 拓扑 位 置 约束 。 例 如 部 署 应 用 程序 服务 (myapp) 与 数据 库 
(db) 服务 相关 的 Pod 时 ，db Pod 可 能 会 部 署 于 如 图 12-10 所 示 的 foo 或 
bar 这 两 个 区 域 中 的 某 节 点 之 上 ， 依 赖 于 数据 服务 的 myapp Pod 对 象 可 部 
署 于 db Pod 所 在 区 域内 的 节点 上 。 当 然 ， 如 果 db Pod 在 两 个 区 域 foo 和 
0 


例如 ,创建 具 有 两 个 拥有 标签 为 <app=db” 的 副本 Pod 作 为 被 依赖 的 
俯 源 ， 它 们 可 能 运行 于 类 似 图 12-5 所 示 的 三 个 太太 中 的 任何 一 个 或 两 个 
Wo 本 示例 中 它们 旋 马 运行 于 两 个 zone 标签 值 不 同 的 节点 之 


~]$ kubectl run db -1 app=db --image=redis:alpine --replicas=2 

~]$ kubectl get pods -1 app=db -o wide -w 

NAME READY STATUS RESTARTS AGE IP NODE 
db-6b97b54df7-gbs16 1/1 Running CC..... node03.ilinux.io 
db-6b97b54df7-rhzrp 1/1 Running ..... node02.ilinux.io 


lm me me Pe 


zone foo 


labelSelector: 
app: db 
topologyKey: zone 


图 12-10 ”Pod 硬 亲 和 性 调度 


于 是 ， 依 赖 于 亲 和 于 这 两 个 Pod 的 其 他 Pod 对 象 可 运行 于 zone 标 签 
值 为 fgo 和 bar 的 区 域内 的 所 有 节点 之 上 。 下 面 的 资源 配置 清单 (deploy- 
with-required-podAffinity.yaml) 中 正 是 定义 了 这 样 一 些 Pod 资 源 ， 它 们 
由 Deployment 控 制 器 所 创建 : 


apiVersion: apps/v1 
kind: Deployment 
metadata: 
name: myapp-with-pod-affinity 
spec: 
replicas: 3 
selector: 
matchLabels: 
app: myapp 
template: 
metadata: 
name: myapp 
labels: 
app: myapp 
spec: 


affinity: 
podAffinity: 
requiredDuringschedulingIgnoredDuringExecution: 
- labelSelector: 
matchExpressions: 
- {key: app, operator: In, values: ["db"]} 
topologyKey: zone 
containers: 
- name: myap 
image: ikubernetes/myapp:vi 


在 调度 示例 中 的 Deployment 控 制 絮 创建 的 Pod 资 源 时 ， 调 度 器 首先 
会 基于 标签 选择 器 查询 拥有 标签 “app=db” 的 所 有 Pod 资 源 ， 接 着 获取 到 
它们 分 别 所 属 的 节点 的 zone 标 签 值 ， 接 下 来 再 查询 拥有 匹配 这 些 标签 
值 的 所 及 后 ， 从 而 完成 太 护 预选。 而 后 根据 优选 西数 计算 这 些 太 后 
的 优先 级 ， 从 而 挑选 出 运行 新 建 Pod 对 和 象 的 节点 。 


需要 注意 的 是 ， 如 果蔬 点 上 的 标签 在 运行 时 发 生 了 更 改 ， 以 致 它 
不 再 满足 Pod 上 的 亲 和 人 性 规则 ， 但 该 Pod 还 将 继续 在 该 节点 上 运行 ， 
此 它 仅 会 影响 新 建 的 Pod 资 源 ;， 另 外 ，]labelSelector 属 性 仅 匹配 与 被 调度 
角 失 Pod 在 同一 名 称 空间 中 的 Pod 资 源 ， 不 过 也 可 以 通过 为 其 添加 
namespace 字 段 以 指定 其 他 名 称 空间 。 


12.3.3 ”Pod 软 亲 和 调 度 


类 似 于 节点 亲 和 人 性 机 制 ，Pod 也 文 持 使 用 
preferredDuringSchedulingIgnoredDuringExecution 属 性 定义 柔性 亲 和 机 
制 ， 调 度 器 会 尽力 确 祭 满足 杀 和 约束 的 调度 逻辑 ， 然 而 在 约束 条 件 不 
能 得 到 满足 时 ， 它 也 允许 将 Pod 对 象 调度 至 其 他 市 点 运行 。 下 面 是 一 
个 使 用 了 Pod 软 亲 和 性 调度 机 制 的 资源 配置 清单 示例 (deploy-with- 
preferred-podAffinity.yaml ) 


apiVersion: appSs/VI 
kind: Deployment 
metadata.: 
name: myapp-with-preferred-pod-affinity 
spec: 
replicas: 3 
selector: 
matchLabels: 
app: myapp 
template: 
metadata.: 
name: myapp 
labels: 
app: myapp 
spec: 
affinity: 
podAffinity: 
preferredDuringSschedulingIgnoredDuringExecution: 
- weight: 80 
podAffinityTerm: 
labelSelector: 
matchExpressions: 
- {key: app, operator: In, values: ["cache"]} 
topologyKey: zone 
- weight: 20 
podAffinityTerm: 
labelSelector: 
matchExpressions: 
- {key: app, operator: In, values: ["db"]} 
topologyKey: zone 
containers: 
- name: myapp 
image: ikubernetes/myapp:v1 


它 定 义 了 两 组 亲 和 性 判定 机 制 ， 一 个 是 选择 cache Pod 所 在 世 点 的 
zone 标签， 并 赋予 了 较 高 的 权重 80， 另 一 个 是 选择 db Pod 所 在 节点 的 
zone 标签 ， 它 有 着 略 低 的 权重 20。 于 是 ， 调 度 右 会 将 目标 节点 分 为 四 


类 : cache Pod 和 db Pod 同 时 所 属 的 zone、cache Pod 单 独 所 属 的 zone、 
db Pod 单 独 所 属 的 zone， 以 及 其 他 所 有 的 zone 。 


12.3.4 Pod 反 亲 和 调 度 


podAffinity 用 于 定义 Pod 对 象 的 亲 和 约 束 ， 对 应 地 ， 将 其 替换 为 
podAntiAffinty 即 可 用 于 定义 Pod 对 象 的 反 亲 和 约束 。 不 过 ， 反 亲 和 人 性 
调度 一 般 用 于 分 散 同一 类 应 用 的 Pod 对 象 等 ， 也 包括 将 不 同安 全 级 别 

的 Pod 对 象 调 度 至 不 同 的 区 域 、 机 架 或 三 点 等 。 下 面 的 资源 配置 清单 
(deploy-with-required-podAntiAffinity.yaml) 中 定义 了 由 同一 
Deployment 创 建 但 彼此 基于 点 位 置 互 斥 的 Pod 对 象 : 


apiVersion: appSs/VI 
kind: Deployment 
metadata.: 
name: myapp-with-pod-anti-affinity 
spec: 
replicas: 4 
selector: 
matchLabels: 
app: myapp 
template: 
metadata.: 
name: myapp 
labels: 
app: myapp 
spec: 
affinity: 
podAffinity: 
requiredDuringSschedulingIgnoredDuringExecution: 
- labelSelector: 
matchExpressions: 
- {key: app, operator: In, values: ["myapp"]} 
topologyKey: kubernetes.io/hostname 
containers: 
- name: myapp 
image: ikubernetes/myapp:v1 


由 于 定义 的 强制 性 反 亲 和 约束 ， 因 此 ， od 
行 于 不 同 的 节点 中 。 不 过 ， 本 集群 中 一 共 只 存在 3 个 万 点 ， 因 此 ， 必 然 
地 会 有 一 个 Pod 对 象 处 于 Pending 状 态 ， 如 下 所 示 : 


~]$ kubectl1 get pods -o wide -1 app=myapp 


NAME READY STATUS RESTARTS AGE IP NODE 

myapp-...-4gcvv 0/1 Pending 0 2S <none> <none> 
myapp-..-788k6 1/1 Running 0 node01.ilinux.io 
myapp-...-cxqv5 1/1 Running O09 node03.ilinux.io 
myapp-...-mk28s 1/1 Running 0 node02.ilinux.io 


类 似 地 ，Pod 反 杀 和 性 调度 也 文 持 使 用 柔性 约束 机 制 ， 在 调度 
时 ， 它 将 尽量 满足 不 把 位 置 相 乒 的 Pod 对 象 调度 于 同一 位 置 ， 但 是 ， 
当 约 束 关 系 无 法 得 到 满足 时 ， 也 可 以 违反 约束 而 调度 。 读 者 可 参考 
podAffinity 的 柔性 约束 示例 将 上 面 的 Deployment 资 源 myapp-with-pod- 
anti-affinity 修 改 为 柔性 约束 并 进行 调度 测试 。 


12.4 污点 和 容忍 度 


污点 (taints) 是 定义 在 节点 之 上 的 键 值 型 属性 数据 ， 用 于 让 市 抬 
拒绝 将 Pod 调 度 运行 于 其 上 ， 除 非 该 Pod 对 象 具有 接纳 节点 污点 的 容 妨 
度 。 而 容忍 度 (tolerations) 是 定义 在 Pod 对 象 上 的 键 值 型 属性 数据 ， 用 
于 配置 其 可 容忍 的 节点 污点 ， 而 且 调 度 嚣 仅 能 将 Pod 对 象 调度 至 其 能 够 
容 妨 该 节 反 污 扩 的 太 点 之 上 ， 如 图 12-11 所 示 。 
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图 12-11 污点 与 容 妨 之 间 的 关系 示意 图 


前 文中 ， 节 点 选择 器 (nodeSelector) 和 市 点 亲 和 性 
(nodeAffinity) 两 种 调度 方式 都 是 通过 在 Pod 对 象 上 添加 标签 选择 器 来 
完成 对 特定 类 型 节点 标签 的 匹配 ， 它 们 实现 的 是 由 Pod 选 择 节 点 的 机 
制 。 而 污点 和 容忍 度 则 是 通过 向 节点 添加 污点 信息 来 控制 Pod 对 象 的 调 
度 结果 ， 从 而 赋予 了 节点 控制 何 种 Pod 对 象 能 够 调度 于 其 上 的 主 控 权 。 
简单 来 说 ， 节 点 亲 和 性 使 得 Pod 对 象 被 吸引 到 一 类 特定 的 和 节点， 而 污点 
则 相反 ， 它 提供 了 让 节点 排斥 特定 Pod 对 象 的 能 力 。 


Kubernetes 使 用 PodToleratesNodeTaints 预 选 策略 和 
TaintTolerationPriority 优 选 画 数 来 完成 此 种 类 型 的 高 级 调度 机 制 。 


12.4.1 定义 污点 和 容忍 度 


污点 定义 在 节点 的 nodeSpec 中 ， 而 容忍 度 则 定义 在 Pod 的 podSpec 
中 ， 它 们 都 是 键 值 型 数据 ， 但 又 都 额外 支持 一 个 效果 (effect) 标记 ， 
语法 格式 为 “key=value: effect”， 其 中 key 和 value 的 用 法 及 格式 与 资源 
注解 信息 相似 ， 而 effect 则 用 于 定义 对 Pod 对 和 象 的 排斥 等 级 ， 它 主要 包 
含 以 下 三 种 类 型 。 


.NoSchedule: 不 能 容 外 此 污点 的 新 Pod 对 象 不 可 调度 至 当 前 克 
点 ， 属 于 强制 型 约束 关系 ， 太 点 上 现存 的 Pod 对 象 不 受 影 啊 。 


:PreferNoSchedule: NoSchedule 的 柔性 约束 版 本 ， 即 不 能 容忍 此 污 
点 的 新 Pod 对 和 象 尽量 不 要 调度 至 人 不 过 无 其 他 市 点 可 供 调 度 
时 也 允许 接受 相应 的 Pod 对 象 。 市 点 上 现存 的 Pod 对 象 不 受 影响 。 


:NoExecute: 不 能 容 妨 此 污点 的 新 Pod 对 象 不 可 调度 至 当 前 节点 ， 
属于 强制 型 约束 关系 ， 而 且 节 点 上 现存 的 Pod 对 象 因 节 点 污点 变动 或 
Pod 容 忍 度 变 动 而 不 再 满足 匹配 规则 时 ，Pod 对 象 将 被 驱逐 。 


此 外 ， 在 Pod 对 象 上 定义 容忍 度 时 ， 它 支持 两 种 操作 符 ， 一 种 是 
等 值 比 较 (Equal) ， 表 示 容 忍 度 与 污点 必须 在 key、value 和 effect 三 者 
之 上 完全 匹配 ; 另 一 种 是 存在 性 判断 〈Exists) ， 表 示 二 者 的 key 和 
effect 必 须 完 全 匹配 ， 而 容忍 度 中 的 value 字 段 要 使 用 空 值 。 


男 外 ， 一 个 节点 可 以 配置 使 用 多 个 污点 ， 一 个 Pod 对 象 也 可 以 有 
多 个 容 妨 度 ， 不 过 二 者 在 进行 匹配 检查 时 应 遵循 如 下 逻辑 。 


1) 首先 处 理 每 个 有 着 与 之 匹配 的 容忍 度 的 污点 。 


2) 不 能 匹配 到 的 污点 上 ， 如 果 存 在 一 个 污点 使 用 了 NoSchedule 效 
用 标识 ， 则 拒绝 调度 Pod 对 象 至 此 节点 。 


3) 不 能 匹配 到 的 污点 上 ， 若 没有 任何 一 个 使 用 了 NoSchedule 效 用 
标识 ， 但 至 少 有 一 个 使 用 了 PreferNoScheduler， 则 应 尽量 避免 将 Pod 对 
象 调 度 至 此 和 点 。 


4) 如 果 至 少 有 一 个 不 匹配 的 污点 使 用 了 NoExecute 效 用 标识 ， 则 
节点 将 立即 驱逐 Pod 对 象 ， 或 者 不 予 调度 至 给 定 节 点 ， 男 外 ， 即 便 容 
和 仿 度 可 以 匹配 到 使 用 了 NoExecute 效 用 标识 的 污点 ， 若 在 定义 容忍 度 时 
还 同时 使 用 tolerationSeconds 属 性 定义 了 容忍 时 限 ， 则 超出 时 限 后 其 也 
将 被 节点 驱逐 。 


使 用 kubeadm 部 署 的 Kubernetes 集 群 ， 其 Master 广 点 将 自动 添加 污 
点 音 县 以 阻止 不 能 容 入 此 污点 的 Pod 对 象 调度 至 此 三 点， 因此 ， 用 户 
手动 创建 的 未 特意 添加 容忍 此 污点 容忍 度 的 Pod 对 象 将 不 会 被 调度 至 
此 节点 : 


~]$ kubectl1 describe node master.ilinux.io 


Name: master .ilinux.io 
Roles: master 
Labels: beta.kubernetes.io/arch=amd64 


beta.kubernetes.io/o0s=l1inux 
kubernetes.io/hostname=master .ilinux.io 
node-role.kubernetes.io/master= 
Taints: node-role.kubernetes.io/master:NoSchedule 
Unschedulable: false 


不 过 ， 有 些 系统 级 应 用 ， 如 kube-proxy 或 者 kube-flannel 等 ， 都 在 
和 质 源 创建 时 束 添 加 上 了 相应 的 容 肪 度 以 确保 它们 被 DaemonSet 探 制 器 
创建 时 能 够 调度 至 Master 节 点 运行 一 个 实例 : 


~]$ kubectl1 describe pods kube-flannel-ds-lsgqr -n kube-system 


Node-Selectors: beta.kubernetes.io/arch=amd64 

Tolerations: node-role.kubernetes.io/master:NoSschedule 
node.kubernetes.io/disk-pressure:Noschedule 
node.kubernetes.io/memory-pressure:NoSschedule 
node.kubernetes.io/not-ready:NoExecute 
node.kubernetes.io/unreachable:NoExecute 


另外， 这 类 Pod 是 构成 Kubermmetes 系 统 的 基础 且 关 键 性 的 组 件 ， 它 
们 甚至 还 定义 了 更 大 的 容忍 度 。 从 上 面 菜 kube-flannel 实 例 的 容忍 度 定 
义 来 看 ， 它 还 能 容 妨 那些 报告 了 磁盘 压力 或 内 存 压力 的 节点 ， 以 及 未 
束 绪 的 节点 和 不 可 达 的 节点 ， 以 确保 它们 能 在 任何 状态 下 正常 调度 至 
集群 下 点 上 运行 。 


12.4.2 ”管理 节点 的 污点 


任何 符合 其 键 值 规范 要 求 的 字符 串 均 可 用 于 定义 污点 信息 : 仅 可 
使 用 字母 、 数 字 、 连 接 符 、 点 号 和 下 划 线 ， 且 仅 能 以 字母 或 数字 开 
头 ， 其 中 键 名 的 长 度 上 限 为 253 个 字符 ， 值 最 长 为 63 个 字符 。 实 践 中 ， 
污点 通常 用 于 描述 具体 的 部 署 规划 ， 它 们 的 键 名 形 如 node-type、node- 
role、node-project 或 node-geo 等 ， 因 此 还 可 在 必要 时 带 上 域名 以 摘 述 其 
额外 的 信息 ， 如 node-type.ilinux.io 等 。 使 用 “kubectl taint* 命 令 即 可 同市 
点 添加 污点 ， 命 令 的 语法 格式 如 下 : 


kubect] taint nodes <node-name> <key>=<value>:<effect> .… 


例如 ， 使 用 “node-type=production: NoSchedule” 定 义 世 点 
node01.ilinux.io: 


~]$ kubectl1 taint nodes node01.ilinux.io node-type=production:NoSchedule 
node "node01.ilinux.io" tainted 


此 时 ，node01 上 已 有 的 Pod 对 象 不 受 影响 ， 但 新 建 的 pod 若 不 能 容 
。 类似 下 面 的 命令 可 以 查看 世 点 上 
人. 熏 忆 言 妃 : 


~]$ kubectl1 get nodes node01.ilinux.io -0 go-template={{.spec.taints}} 
[map[value:production effect:NoSchedule key:node-typel]] 


需要 注意 的 是 ， 即 便 是 同一 个 键 值 数据 ， 帮 其 效用 标识 不 同 ， 则 
其 也 分 属于 不 同 的 污点 信息 ， 例 如 ， 将 上 面 命令 中 的 效用 标识 定义 为 
PreferNoSchedule 再 添加 一 次 : 


~]$ kubectl1 taint nodes node01.ilinux.io node-type=production:PreferNoSchedule 
node "node01.ilinux.io" tainted 


删除 某 污 点 ， 仍 然 通过 kubectl taint 命 令 进行 ， 但 要 使 用 如 下 的 命 
令 格 式 ， 省 略 殖 用 标识 则 表示 删除 使 用 指定 键 名 的 所 有 污点 ， 否 则 束 
只 删除 指定 键 名 上 对 应 效用 标识 的 污点 : 


kubectl1 taint nodes <node-name> <key>[:<effect>]- 


a 删除 node01 上 node-type 键 的 效用 标识 为 “NoSchedule” 的 污 


~]$ kubectl1 taint nodes node01.ilinux.io node-type:NoSchedule- 
node "node01.ilinux.io" untainted 


大 要 删除 使 用 指定 键 名 的 所 有 污点 ， 则 在 删除 命令 中 省 略 效 用 标 
识 即 能 实现 ， 例 如 : 


~]$ kubect1 taint nodes node01.ilinux.io node-type- 
node "node01.ilinux.io" untainted 


删除 节点 上 的 全 部 污点 信息 ， 通 过 kubectl patch 命 令 将 万 点 属性 
spec. taints 的 信 证 接 章 人 x 即 站 可 ， 例如 : 


~]$ kubectl1 patch nodes node01.ilinux.io -p '{"spec":{"taints":[]}}" 
node "node01.ilinux.io" patched 


节点 污点 的 变动 会 影响 到 新 建 Pod 对 象 的 调度 结果 ， 而 且 使 用 
NoExecute 进 行 标识 时 还 会 影响 到 节点 上 现 有 的 Pod 对 象 。 


12.4.3” ”Pod 对 象 的 容忍 度 


Pod 对 和 象 的 容 妨 度 可 通过 其 spec.tolerations 字 上 段 进 行 添 加 ， 根 据 使 
用 的 操作 符 不 同 ， 主 要 有 两 种 可 用 的 形式 : 一 种 是 与 污点 信息 完全 匹 
配 的 等 值 关 系 ; 另 一 种 是 判断 污点 信息 存在 性 的 匹配 方式 。 使 用 Equal 
操作 符 的 示例 如 下 所 示 ， 其 中 tolerationSeconds 用 于 定义 延迟 驱逐 当前 
Pod 对 和 象 的 时 长 : 


tolerations: 

- key: "key1" 
operator: "Equal" 
value: "value1" 
effect: "NoExecute" 
tolerationSeconds: 3600 


使 用 存在 性 判断 机 制 的 容忍 度 示 例如 下 所 示 : 


tolerations: 

- key: "key1" 
operator: "Exists" 
effect: "NoExecute" 
tolerationSeconds: 3600 


实践 中 ， 帮 集群 中 的 一 组 机 器 专用 于 为 运行 非 生产 型 的 容 右 应 用 
而 备 置 ， 而 且 它 们 可 能 随时 按 需 上 下 线 ， 那 么 加 应 该 为 其 添加 污点 信 
思 ， 以 确保 仅 那些 能 容 仆 此 污点 的 非 生产 型 Pod 对 象 可 以 调度 其 上 。 
男 外 ， 菏 些 有 着 特殊 硬件 的 节点 需 要 专用 于 运行 一 类 有 着 此 类 硬件 资 
源 需 求 的 Pod 对 象 时 ， 例 如 ， 那 些 有 着 SSD 或 GPU 的 设备 ， 也 应 该 为 其 
添加 污点 信息 以 排除 其 他 的 Pod 对 象 。 


12.4.4 问题 下 所 标 识 


Kubernetes 目 1.6 版 本 起 支持 使 用 污点 自动 标识 问题 节点 ， 它 通过 
节点 控制 器 在 特定 条 件 下 自动 为 节点 添加 污点 信息 实现 。 它 们 都 使 用 
NoExecute 效 用 标识 ， 因 此 不 能 容忍 此 类 污点 的 现 有 Pod 对 象 也 会 遭 到 
驱逐 。 目 前 ， 内 建 使 用 的 此 类 污点 包含 如 下 几 个 。 


‘node.kubernetes.io/not-ready: 节点 进入 “NotReady” 状 态 时 被 目 动 
添加 的 污点 。 


.node.alpha.kubernetes.io/unreachable: 下 点 进入 “NotReachable” 状 
态 时 被 上 自 动 添加 的 污 ， 点 


-node.kubernetes.io/out-of-disk: 节点 进入 “OutOfDisk” 状 态 时 被 自 
动 添加 的 污点 。 


.node.kubernetes.io/memory-pressure: 六 点 内 存 资 源 面 临 压力 。 


:node.kubernetes.io/disk-pressure: 点 做 盘 资 源 面临 压力 。 
:node.kubernetes.io/network-unavailable: 节点 网 络 不 可 用 。 


‘node.cloudprovider.kubernetes.io/uninitialized: kubelet 由 外 部 的 
环境 程序 司 动 时 ， 它 将 目 动 为 节点 添加 此 污点 ， 行 到 云 控制 器 管理 
中 的 控制 如 初始 化 此 忆 点 时 再 将 其 删除 。 


不 过 ，Kubernetes 的 核心 组 件 通常 都 要 容忍 此 类 的 污点 ， 以 确保 
其 相应 的 DaemonSet 控 制 器 能 够 无 视 此 类 污点 ， 于 节点 上 部 署 相 应 的 
关键 性 Pod 对 象 ， 例 如 kube-proxy 或 kube-flannel 等 。 


12.5 “Pod 优 选 级 和 抢占 式 调度 


Kubernetes 自 1.8 版 本 起 开始 支持 Pod 资 源 的 优选 级 机 制 ， 它 用 于 表 
现 一 个 Pod 对 象 相 对 于 其 他 Pod 对 象 的 重要 程度 。 一 个 Pod 对 象 无 法 被 
调度 时 ， 调 度 句 会 竹 试 抢占 (驱逐 ) 较 低 优先 级 的 Pod 对 象 ， 以 便 可 
以 调度 当前 Pod。 男 外 ， 在 Kubernetes 1.9 和 更 高 版 本 中 ， 优 先 级 还 会 
影 啊 节 点 上 Pod 的 调度 顺序 和 豫 逐 次 序 。 


不 过 ，Pod 优 选 级 和 抢占 机 制 默认 处 于 禁用 状态 ， 如 需 局 用 ， 则 
需要 同时 为 kube-apiserver、kube-scheduler 和 kubelet 程 序 的 “--feature- 
gates” 选 项 添加 “PodPriority=true” 条 目 。 添 加 完成 后 ， 事 先 创建 好 优先 
级 类 别 ， 并 在 创建 Pod 资 源 时 通过 priorityClassName 属 性 指定 其 所 属 的 
优选 级 类 别 即 可 。 


此 种 特性 目前 仍 处 于 Alpha 阶 段 ， 因 此 ， 本 章 不 再 对 其 进行 过 多 的 
描述 ， 感 兴趣 的 读者 可 参考 文档 进行 测试 。 


12.6 ”本 章 小 结 


本 章 讲解 了 Kubernetes 默 认 调 度 器 的 分 步调 度 机 制 ， 搞 述 了 各 预 
选 案 略 和 优选 国 数 的 功能 ， 并 对 节点 杀 和 性 调度 、Pod 亲 和 性 调度 以 
及 基于 污点 和 容忍 的 高 级 调度 方式 进行 了 重点 说 明 。 


第 13 革 Kubernetes 系 统 扩 展 


Kubernetes 系 统 的 扩展 和 增强 既 包 括 扩 展 API Server 所 支持 的 资源 
类 型 及 相关 声明 式 功 能 的 实现 ， 以 及 消除 集群 的 单 点 以 实现 集群 的 高 
可 用 等 ， 也 包括 如 何 将 系统 增强 为 一 个 完整 意义 上 的 PaaS 平 台 ， 并 以 
DevOps 文 化 为 驱动 改善 工作 流程 等 。 


13.1 自 定 义 资 源 类 型 (CRD ) 


Kubernetes API 默 认 提 供 的 众多 的 功能 性 资源 类 型 可 用 于 容器 编排 
以 解决 多 数 场景 中 的 编排 需求 。 然 而 ， 有 些 场景 也 许 要 借助 于 额外 的 
或 更 高 级 别 的 编排 抽象 ， 例 如 引入 集群 外 部 的 一 些 服务 并 以 资源 对 象 
的 形式 进行 管理 ， 再 或 者 把 Kubernetes 的 多 个 标准 资源 对 象 合 并 为 一 
个 单一 的 更 高 级 别 的 资源 抽象 ， 等 等 。 而 这 类 API 扩 展 抽 象 通 常 也 应 
该 兼容 Kubernetes 系 统 的 基本 特性 ， 如 文 持 kubectl 管 理工 具 、CRUD 及 
watch 机 制 、 标 签 、etcd 存 储 、 认 证 、 授 权 、RBAC 及 审计 ， 等 等 ， 从 
而 使 得 用 户 可 将 精力 集中 于 构建 业务 逻辑 本 号。 


目前 ， 扩 展 Kubernetes API 的 常用 方式 有 三 种 : 使 用 CRD 
(CustomResourceDefinitions) 自 定 义 资源 类 型 、 开 发 自 定 义 的 API 
Server 并 聚合 至 主 API Server， 以 及 定制 扩展 Kubernetes 源 码 。 其 中 ， 
CRD 最 为 易 用 但 限制 颇 多 ， 目 定义 API Server 更 宣 于 弹性 但 代码 工作 量 
偏 大 ， 而 仅 在 必须 添加 新 的 核心 类 型 才能 确保 专用 的 Kubernetes 集 群 
功能 正常 时 才 应 该 定制 系统 源码 。 


在 某 种 程度 上 ，Kubernetes API Server 可 以 看 作 一 个 JSON 方 案 的 
数据 库存 储 系统 ， 它 内 建 了 众多 数据 模式 (资源 类 型 ， 以 etcd 为 存 
储 后 端 ， 支 持 存储 和 检索 结合 内 建 模 式 进行 实例 化 的 数据 项 (对 
象 ) 。 作 为 客户 端 ， 控 制 絮 会 收 到 有 关 这 些 资源 对 象 变动 的 通知 ， 并 
在 啊 应 过 程 中 操纵 这 些 对 象 及 相关 的 其 他 资源 ， 或 者 将 这 些 更 改 反 映 
到 外 部 系统 (如 云端 的 软件 负载 平衡 器 ) 。 从 这 个 角度 进行 类 比 ， 
CRD 就 像 是 由 用 户 为 Kubernetes 存 储 系统 提供 的 目 定义 数据 模式 ， 基 
于 这 些 模式 进行 实例 化 的 数据 项 一 样 可 以 存 入 系统 中 。 


CRD 并 非 设 计 用 来 取代 Kubernetes 的 原生 资源 类 型 ， 而 是 用 于 补 
充 一 种 简单 易 用 的 更 为 灵活 和 更 高 级 别 的 自 定 义 API 资 源 的 方式 。 虽 
然 目前 在 功能 上 仍 存 在 不 少 的 局 限 ， 但 对 于 大 多 数 的 需求 场景 来 说 ， 
CRD 的 表现 已 经 足够 好 ， 因 此 在 满足 需求 的 前 提 下 是 首选 的 API 资 源 
类 型 扩展 方案 。 


13.1.1 创建 CRD 对 象 


CRD 上 自 Kubernetes 1.7 版 开始 引入 ， 并 目 1.8 版 起 完全 取代 其 前 刁 
TPR (ThirdParty-Resources) ， 其 设计 目标 是 无 须 修改 Kubernetes 源 代 
码 束 能 扩展 它 文 持 使 用 API 资 源 类 型 。CRD 本 号 也 是 一 种 资源 类 型 ， 隶 
属于 集群 级 别 ， 实 例 化 出 特定 的 对 象 之 后 ， 它 会 在 API 上 注册 生成 GVR 
类 型 URL 端 点 ， 并 能 够 作为 一 种 资源 类 型 被 使 用 并 实例 化 相应 的 对 
象 。 上 自 定 义 资源 类 型 之 前 ， 选 定 其 使 用 的 API 群 组 名 称 、 版 本 及 新 建 的 
资源 类 型 名 称 ， 根 据 这 些 信息 即 可 创建 自 定义 资源 类 型 ， 并 创建 自 定 
义 类 型 的 资源 对 象 ， 其 流程 如 图 13-1 所 示 。 


kind:CustomResourcDefinition kind:CustomResourcType 


Custom Resourc 


CustomResourcelype Object 


Object 
图 13-1 创建 目 定义 资源 类 型 及 目 定义 类 型 的 资源 对 象 


下 面 的 配置 清单 中 定义 了 一 个 名 为 users.auth.ilinux.io 的 CRD 资 源 对 
象 ， 它 的 群 组 名 称 为 auth.ilinux.io， 仪 支持 一 个 版 本 级 别 vlbetal1， 复 数 
形式 为 users， 隶 属于 名 称 空间 级 别 ， 因 此 ， 它 的 对 象 在 API 上 的 URL 路 
径 前 缀 为 / apis/auth.ilinux.io/vlbetal/namespace/NS_NAME/users/: 


apiVersion: apiextensions,.k8s.io/vibeta1 
kind: CustomResourceDefinition 
metadata: 
name: users.auth.ilinux.io 
spec: 
group: auth.ilinux.io 
version: vibetai 
names : 
kind: User 
plural: users 
singular: user 
shortNames: 
- U 
scope: Namespaced 


配置 清单 中 ，spec 般 套 使 用 的 字段 都 能 够 见 名 知 义 ， 这 里 需要 特别 
说 明 的 是 ，metadata.name 字 段 的 值 必须 等 同 于 spec 字 段 中 
的 “<names.plural>.<group>” 合 并 起 来 的 形式 。 将 清单 中 的 CRD 资 源 创 
建 于 Kubernetes 集 群 中 之 后 ， 继 而 创建 一 个 新 的 
CustomResourceDefinition 类 型 的 对 象 ， 例 如 ， 使 用 下 面 的 命令 列 出 集 
群 上 的 CRD 对 象 时 ， 命 令 结果 将 显示 出 如 下 资源 名 称 及 创建 时 间 状 态 


信息 


~]$ kubectl get crd 
NAME CREATED AT 
users.auth.ilinux.io 2018-08-24T12:51:54Z 


现在 ， 在 API 群 组 auth.ilinux.io/vlbetal 中 ，users 已 经 是 一 个 名 称 空 
间 级 别 的 可 用 和 质 源 类 型 局 可 按 需 创建 出 任意 数量 的 users 类 型 的 对 
下 面 就 是 一 个 资源 清单 示例 ， 它 定义 了 一 个 名 为 admin 的 users 对 


apiVersion: auth,iIlinux,Io/Xv1betal 
kind: User 
metadata: 
name: admin 
namespace: default 
spec: 
userID: 1 
email: k8s@ilinux.io 
groups: 
- Superusers 
- adminstrators 
password: ikubernetes 


目 害 义 资 源 类 型 users 并 林 限 制 其 spec 字 段 中 可 崩 套 使 用 的 字段 及 其 
数据 类 型 ， 于 是 用 户 可 按 需 随意 使 用 任何 字段 名 及 字段 值 ， 例 如 上 面 
的 资源 清单 中 使 用 的 userID、email 和 groups 等 字段 。 资源 创建 完成 后 即 
可 使 用 users 作 为 类 型 标识 使 用 kubectl 命 令 完成 资源 对 象 的 管理 ， 包 括 
查看 、 删 除 、 修 改 等 操作 。 例 如 ， 将 清单 中 的 自 定义 资源 创建 于 名 称 
空间 中 ， 而 后 使 用 类 似 如 下 的 命令 获取 相关 的 状态 信息 : 


~]$ kubect] get users -n default 
NAME AGE 
admin 10s 


根据 API 对 象 GVR 格 式 的 URL 规 范 ，users 资 源 的 对 象 admin 的 引用 
路 径 为 /apis/auth.ilinux.io/vlbetal/namespaces/default/users/admin， 这 一 
点 可 以 通过 describe 命 令 予 以 证 实 。 而 要 删除 自 定 义 的 users 对 象 
admin， 只 要 使 用 通用 格式 的 kubect 命 令 即 可 ， 如 “kubectl delete users 
admin”， 或 者 使 用 陈述 式 对 象 配 置 命令 “kubectl delete-f<filename>”。 


13.1.2” 目 定义 资源 格式 竹 证 


除了 对 操作 请 求 进行 喘 份 认证 和 授权 检查 之 外 ， 对 象 配 置 的 变动 
在 存 入 etcd 之 前 还 需要 经 由 准 入 控制 紫 的 核验 ， 尤 其 古 验 证 型 
(validation) 控制 器 会 检查 传 入 的 对 象 格式 是 否 符合 有 效 格式 ， 包 括 
征 否 设 定 了 不 符合 定义 的 数据 类 型 值 ， 以 及 是 否 违反 了 字段 的 限制 规 


则 等 。 


Kubernetes 自 1.9 版 本 起 支持 为 CRD 定 义 验证 (validation 字 上 段 ) 机 
制 用 以 定义 CRD 可 用 的 有 效 字 段 等 ， 这 在 将 设计 的 自 定义 资源 公开 应 
用 时 非常 重要 。 自 定义 资源 可 使 用 OpenAPI 模 式 声明 验证 规则 ， 该 模 
式 是 JSON 模 式 的 子 集 。 需 要 注意 的 是 ，OpenAPI 架 构 并 不 能 支持 
JSON 架 构 的 所 有 功能 ， 而 CRD 验 证 也 不 能 支持 OpenAPI 架 构 的 所 有 功 
能 ， 不 过 ， 对 于 大 多 数 情 况 来 说 ， 它 足够 用 了 。 


@ 提示 。 CRD 的 validation 中 文 持 使 用 的 限制 机 制 、 数 据 类 型 
及 数据 格式 等 请 参考 其 API 手 册 。 


下 面 是 一 个 配置 清单 片段 ， 将 其 合并 添加 到 13.1.1 丰 中 CRD 对 象 
users.auth.ilinux.io 配 置 清 单 的 spec 内 即 能 生效 。 它 分 别 定 义 了 userID、 
groups、email 和 password 字 段 的 数据 类 型 ， 并 指定 了 userID 字 段 的 取 值 
范围 ， 以 及 password 字 段 的 数据 格式 ， 而 且 还 通过 required 指 定 userID 
和 groups 是 必 选 字段 : 


spec: 
validation: 
openAPIV3Schema: 
properties.: 
spec: 
properties: 
userID: 
type: integer 
minimum: 1 
maximum: 65535 
groups: 
type: array 
email: 
type: string 
password: 
type: string 


format: password 
required: ["userID","groups"] 


限制 了 每 个 字段 的 数据 类 型 之 后 ， 验 证 机 制 会 检查 创建 或 修改 操 
作 中 提供 的 每 个 字段 值 等 是 否 违反 了 格式 有 要求 ， 任 何 的 核验 失败 都 会 
导 敏 所 入 操 作息 拒 绝 。 下 面 的 内 容 是 某 次 创建 操作 返回 的 错误 提示 ， 
忆 江 水合 命令 提供 的 对 象 配 置信 息 违反 了 userID 字 段 的 取 值 范围 ， 并 且 
缺少 必 选 字段 : spec.groups 。 


The User "tony" is invalid: [] : .… 

.: Validation failure list: 

spec.userID in body should be less than or equal to 65535 
spec.groups in body is required 


目 Kubernetes 1.11 版 本 开始 ， kubectl 即 使 用 有 服务 铬 侧 对 象 信息 打 印 
机 制 ， 这 意味 看 将 由 API Server 决 定 kubectl get 命 令 结果 会 显示 哪些 字 
段 。 在 CRD 资 源 中 ， 可 在 spec.additionalPrinterColumns 中 袖 套 定义 在 对 
象 的 详细 信息 中 要 打印 的 字段 列表 。 下 面 的 配置 清单 片断 定义 了 要 为 
users 类 型 的 对 象 显示 相关 的 四 个 字段 ， 将 其 合并 至 前 面 定义 的 CRD 对 
单 的 spec 字 段 中 ， 重 新 应 用 到 集群 中 并 确保 其 正常 生 
交 


spec: 
additionalPrinterColumns : 

- name: userID 
type: integer 
description: The user ID. 
JSONPath: .spec.userID 

- name: groups 
type: string 
description: The groups of the user. 
JSONPath: .spec.groups 

- name: email 
type: string 
description: The email address of the user. 
JSONPath: .spec.email 

- name: password 
type: string 
description: The password of the user account. 
JSONPath: .spec.password 


以 上 四 个 字段 会 显示 在 get、describe 等 命令 查看 users 类 型 的 对 象 
状态 信息 的 输出 结果 中 


~]$ kubectl1 get users admin 
NAME USERID GROUPS EMAIL PASSWORD 
admin 1 [superusers administrators] k8s@ilinux.io ikubernetes 


当然 ， 在 对 象 中 以 明文 字符 串 保存 密码 并 不 是 一 个 好 的 选择 ， 真 
3 到 时 ， 应 该 使 用 Secret 对 象 保存 密 钥 信 息 ， 并 在 users 对 象 中 进行 
引用 。 


13.1.3” 子 资 源 


可 能 有 读者 已 经 注意 到 ， 前 面目 定义 资源 users 的 对 象 admin 在 其 
详细 状态 信息 输出 中 没有 类 似 核 心 资源 的 status 字 段 ， 该 字段 是 一 种 用 
于 保存 对 象 当 前 状态 的 子 资 源 。 在 Kubernetes 系 统 的 声 明 式 API 中 ， 
status 字 上 段 至 关 重 要 ， 它 由 Kubermnetes 系 统 目 行 维护 ， 相 关 的 控制 器 在 
和 解 循环 中 持续 与 API Server 进 行 通信 ， 并 人 负责 确保 status 字 上 段 中 的 状 
态 匹配 spec 字 段 中 定义 的 期 望 状 态 ° 


在 Kubernetes 1.10 版 本 之 前 ， 目 定义 资源 的 API 端 点 不 区 分 7spec 和 hl 
status 字 和 上段， 而 自 1.10 版 本 起 ， 自 定义 次 源 开始 支持 通过 /status 子 资 务 源 
的 方式 提供 对 象 的 当前 状态 ， 虽 然 它 它 仍然 不 会 显示 于 获取 状态 信息 的 
| 但 客户 端 可 通过 对 象 的 子 URL 路 和 至 来 获取 状态 信 

° 此 特性 在 1.11 版 本 中 已 经 升级 至 beta 级 别 。 


在 CRD 中 为 目 定义 资源 启用 status 字 段 的 方式 非常 简单 ， 只 需要 为 
其 定义 spec.subresources.status 字 段 即 可 ， 其 内 骨 的 字段 等 由 系统 上 自行 
维护 ， 用 户 无 须 提供 任何 额外 的 配置 。 它 的 使 用 格式 如 下 : 


spec: 
subresources: 
status: {} 


将 上 面 配置 清单 中 的 配置 片段 合并 至 前 面 创建 的 CRD 对 象 users 的 
配置 中 ， 并 完成 活动 对 象 的 修改 即 可 在 其 实例 化 出 的 对 象 上 通 
过 /status 获 取 状 态 信息 ， 如 对 象 adamin 的 状态 引用 路 径 
0 ilinux. lo/v lbetal/namespaces/default/users/admin/status ° 不 
在 没有 相应 资源 控制 如 的 情形 下， 活动 对 象 状 态 的 非 计划 内 变动 
噬 不 人 实时 反映 到 status 中 ， 也 不 会 向 spec 定 义 的 期 望 状态 转换 。 


事实 上 ， 如 有 果 有 相应 的 资源 控制 妖 维 护 自 定义 的 资源 类 型 时 ， 
可 以 在 配置 日 定义 资 和 源 对 象 时 使 用 scale 子 次 从 源 和 status 子 资 协同 
类 似 Deployment 或 StatefulSet 等 控制 右 一 样 对 象 规模 的 伸缩 功能 。 它 的 
定义 格式 如 下 : 


spec: 
status: {} 
scale: 
specReplicaspPath: 
statusReplicasPath: 
labelSelectorPath: 


需要 注意 的 是 ，scale 字 段 必 须 与 status 字 段 一 起 使 用 ， 由 控制 器 通 
过 status 获 取 对 象 当 前 的 副本 数量 ， 并 与 spec 字 段 内 舱 套 的 用 于 指定 副 
本 数量 的 字段 〈 例 如， 常用 的 replicas) 进行 比较 来 确定 其 所 需要 执行 
的 伸缩 操作 ， 而 后 再 将 伸缩 操作 的 结果 更 新 至 status 字 段 中 。 上 面 的 配 
置 格式 中 ，scale 的 各 内 骸 字 段 功 用 说 明 具 体 如 下 。 


:specReplicasPath<string> : 引用 定义 在 spec 中 用 于 表示 期 望 的 副 
本 数量 的 字段 ，JSONPath 格 式 ， 如 .spec.replicas。 


statusReplicasPath<string> : 引用 保存 在 status 中 用 于 表示 对 象 的 
当前 副本 数量 的 字段 ，JSONPath 格 式 ， 如 .status.replicas 。 


“labelSelectorPath<string> : 可 选 字段 ， 但 知 要 与 HPA 结 合 使 用 则 
是 必 选 字段 ， 用 于 引用 status 中 用 于 表示 使 用 的 标签 选择 右 字 段 ， 
JSONPath 格 式 ， 如 .status.labelSelector 。 


为 某 CRD 资 源 定义 scale 子 资源 之 后 ， 即 可 实例 化 出 支持 规模 伸缩 
的 目 定 义 资源 对 象 。 但 必须 存在 一 个 相应 的 资源 控制 器 来 持续 维护 相 
应 的 自 定义 资源 对 象 ， 以 确保 其 当前 状态 匹配 期 望 的 状态 。 满足 条 件 
后 ， 类 似 于 Deployment 资 源 对 象 等 ， 使 用 “kubectl scale” 命 令 束 能 完成 
对 自 定 义 资源 对 象 规模 的 手动 伸缩 。 


13.1.4 ”使 用 资源 类 别 


类 别 (categories) 是 Kubemetes 1.10 版 本 引入 的 一 种 分 组 组 织 
定义 资源 的 方法 ， 定 义 CRD 对 象 时 为 其 指定 一 个 或 多 个 类 别 ， 可 以 通 
过 kubectl get<category-name> 命 令 列 出 该 类 别 中 的 所 有 目 定 义 资源 对 
象 ，all 就 是 一 个 常用 的 内 建 资 源 类 别 。 例 如 ， 为 前 面 定 义 的 CRD 对 象 
users 的 specnames 字 段 中 额外 内 般 如 下 配置 ， 便 能 使 得 users 资 源 类 型 
下 的 所 有 对 和 象 都 隶属 于 al 类 别 : 


spec: 
names: 
categories: 
- all 


categories 字 段 的 值 是 目 定义 资源 所 属 的 分 组 资源 列表 。 而 后 ， 创 
建 的 所 有 目 定 义 类 型 users 的 对 象 都 能 够 通过 “kubectl get all]” 命 令 进行 
获取 : 


~]$ kubectl1 get all 


NAME USERID GROUPS EMAIL 
user.auth.ilinux.io/admin 1 [superusers administrators] Kk8s@ilinux.io 


13.1.5 ”多 版 本 支持 


Kubemetes 原 生 资 源 的 一 个 引 人 注 目的 特性 是 它们 能 够 在 API 版 本 
之 间 目 动 和 透明 地 迁移 。 资 源 的 使 用 者 可 以 使 用 混合 API 版 本 ， 并 且 
都 能 获得 他 们 所 期 望 的 资源 有 版本。 而 目 Kubernetes 1.11 版 本 开始 ， 
CRD 文 持 多 个 版 本 ， 但 它们 之 间 的 转换 必须 手动 完成 。 


在 CRD 上 使 用 多 版 本 机 制 时 ， 将 spec.version 字 段 奉 换 为 
spec.versions 字 段 ， 并 将 文 持 的 各 版 本 以 对 象 列表 的 形式 给 出 定义 即 
可 。 不 过 ， 多 版 本 并 存 时 ， 仅 其 中 一 个 版 本 且 必 须 有 一 个 版 本 应 标记 
为 存储 〈spec.versions[].storage 字 段 ) 版 本 。 下 面 的 配置 清单 片断 中 定 
义 了 两 个 API 版 本 ， 其 中 仅 vlbetal 标 记 为 了 storage: 


spec: 
versions: 

- name: vibetai 
served: true 
storage: true 

- name: vibeta2 
served: true 
storage: false 


将 上 述 配 置 清 单 版 本 并 入 此 前 定义 的 users 资 源 配置 清单 中 并 应 用 
于 活动 对 象 后 再 创建 相应 类 型 的 自 定 义 对 象 时 就 可 以 通过 两 个 不 同 的 
API 版 本 之 一 来 完成 。 


13.1.6_” 目 定义 控制 右 基 础 


仅 借 助 于 CRD 完 成 资源 自 定 义 本 身 并 不 能 为 用 户 带 来 太 多 的 价 
值 ， 它 只 是 资源 类 型 的 定义 ， 只 是 提供 了 JSON 格 式 的 数据 范式 及 存 取 
相关 数据 的 能 力 ， 至 于 如 何 执行 数据 相关 的 业务 逻辑 ， 时 刻 确保 将 
status 中 的 状态 移 向 spec 中 的 状态 则 是 由 封装 于 控制 器 中 的 代码 来 负责 
实现 的 。 相 应 地 ， 为 自 定义 资源 类 型 提供 业务 逻辑 代码 的 控制 器 需要 
由 用 户 自行 开发 ， 并 运行 为 API Server 的 客户 端 程序 (通常 是 托管 运行 
于 Kubernetes 系 统 之 上 ， 类 似 于 Ingress 控 制 器 ) ， 这 就 是 所 谓 的 自 定义 
控制 器 (Custom Controller) 。 换 句 话 讲 ， 某 特定 的 CRD 资 源 的 相关 对 
象 发 生变 动 时 ， 如 何 确保 它 的 当前 状态 不 断 地 接近 期 望 的 状态 并 非 API 
Server 的 功能 ， 而 是 相关 的 专用 控制 器 组 件 。 


事实 上 ， 目 定义 控制 硕 不 仅仅 能 够 用 于 管理 CRD 资 源 ， 用 户 也 完 
全 可 以 仅 针 对 系统 内 建 的 核心 类 型 对 象 开发 更 高 级 别 的 控制 器 ， 这 些 
对 象 类 型 包括 Service、Deployment、ConfigMap 等 。 不 过 ， 对 于 每 个 
至 少 应 该 存在 一 个 相关 的 自 定义 控制 器 ， 如 
13-2 上 所 未 。 


Clients | 


API server 


Core (builtin) Resources 


Custom Resources (CRD) 


MM ES MyLogs 


Controller Manager 


图 13-2” Kubernetes 核 心 资源 与 CRD 


人 简单 来 说 ， 控 制 右 负责 持续 监视 资源 变动 ， 根 据 资源 的 spec 及 
status 中 的 信息 执行 某 些 操作 逻辑 ， 并 将 执行 结 采 更 新 至 资源 的 status 
中 。 目 定义 控制 右 同 样 担负 着 类 似 的 职责 ， 只 不 过 一 个 特定 的 控制 右 
通常 仅 负 责 管理 一 部 分 特定 的 资源 类 型 ， 并 执行 专 有 管理 逻辑 。 


Kubernetes 系 统 内 建 了 许多 控制 器 ， 如 NodeController 、 
ServiceController 等 ， 它 们 打包 在 一 起 并 作为 一 个 统一 守护 进程 kube- 
controller-manager。 这 些 控制 右 基 本 上 都 遵循 同一 种 模式 以 完成 资源 管 
该 模式 通常 可 描述 为 三 种 特性 : 声明 式 API、 异 步 和 水 平 式 处 
理 。 


.声明 式 API: 用 户 定义 期 望 的 状态 而 非 要 执行 的 特定 操作 ， 如 使 用 
kubectl apply 命 令 将 请 求 发 送 至 API Server 存 储 于 etcd 中 ， 并 由 API 
Server 做 出 处 理 啊 应 。 


异步 : 客户 端的 请 求 于 API Server 存 储 完成 之 后 即 返 回 成 功 信息 ， 
而 无 须 等 待 控制 器 执 行 的 和 解 循环 结束 。 


水平 式 处 理 〈level-based) : 同一 对 象 有 多 次 变动 事件 待 处 理 时 ， 
控制 器 仅 需 要 处 理 其 最 新 一 次 的 变动 。 这 种 根据 最 新 观察 结果 而 非 历 
中 变化 来 和 解 status 和 spec 的 机 制 即 为 水 乎 式 处 理 机 制 。 


自 定义 控制 器 实现 自 定义 资源 管理 行为 的 最 佳 方法 同样 是 遵循 此 
类 控制 器 模式 进行 程序 开发 ， 目 前 ， 大 部 分 开发 接口 都 是 基于 Golang 
语言 来 实现 的 ， 相 关 代 码 位 于 客户 端 库 的 client-go/go/tools/cache 和 
client-gomutil/workqueue 目 孙 中 。 


人 简单 来 说 ， 控 制 絮 包含 两 个 重要 组 件 : InformervSharedInformer 和 
Workqueue， 前 者 负 责 监 视 资源 对 象 当 如 状态 的 更 改 ， 并 将 事件 发 送 至 
后 者 ， 而 后 由 处 理 函 数 进 行 处 理 ， 如 图 13-3 所 示 。 


3 


kube-controller-manager kube-apiserver 
Informer Queue Controller 
ListWatch.ListFunc namespace/name queue.Get 
ListWatch.WatchFunc es if created: 
了 ObjectCreated 
namespace/name if updated: 
3 ObjectUpdated 
AddFunc namespace/name if deleted: 
UpdateFunc es ObjectDeleted 
DeleteFunc 和 
namespace/name 


图 13-3 ”处 理 器 事件 流动 示意 图 (图 片 来 源 : 


https://medium.com/@trstringer ) 


Informer 主 要 由 Listwatcher、ResourceEventHandler 和 ResyncPeriod 
三 类 函数 组 件 进行 构造 。 


:Listwatcher 是 应 用 于 特定 名 称 空 间 中 特定 资源 对 象 的 列表 函数 
(listFunc) 和 监视 函数 (watchFunc) ， 并 结合 字段 选择 器 为 控制 器 精 
确 限定 关注 的 资源 对 象 。 


.ResourceEventHandler 负 责 处 理 资 源 对 象 状 态 改 变 产 生 的 相关 通 
知 ， 其 分 别 使 用 AddFunc、UpdateFunc 和 DeleteFunc 三 个 函数 完成 对 象 
的 创建 、 更 新 和 删除 操作 。 


:ResyncPeriod 定 义 控制 器 遍历 缓存 中 的 所 有 项 目 并 触发 运行 
UpdateFunc 的 频率 ， 即 和 解 循 环 的 执行 频 度 。 较 高 的 频 度 对 于 控制 絮 
普 过 菏 次 更 新 或 此 前 的 更 新 操作 执行 失败 时 非常 有 用 ， 但 会 对 系统 次 
源 带 来 较 高 的 压力 ， 因 此 具体 的 时 长 需要 人 全面、 系统 地 进行 权衡 。 


Informer 古 控制 恬 的 私有 组 件 ， 它 为 相关 资源 对 象 创建 的 绥 存 信息 
仅 可 供 当 前 控制 器 使 用 。 而 在 Kubernetes 系 统 上 ， 同 一 资源 对 象 支持 多 


个 控制 器 共同 处 理 ， 而 且 多 个 控制 器 监视 同一 资源 对 象 也 是 较为 常见 
的 情形 ， 于 是 ， 一 个 更 高 效 的 方式 是 使 用 蔡 代 解决 方案 SharedInformer 
和 Workqueue。SharedInformer 文 持 在 监控 同类 资源 对 象 的 控制 器 之 间 
创建 共享 缓存 ， 这 有 效 降低 了 内 存 资 源 开销 ， 而 且 它 也 仪 需要 在 上 游 
的 API Server 中 注册 创建 一 个 监视 器 ， 即 能 显著 减轻 上 游 服 务 器 的 访问 
压力 。 因 此 ， 较 之 Informer，SharedInformer 才 是 更 为 常用 的 解决 方案 。 


不 过 ，SharedInformer 无 法 跟踪 每 个 控制 絮 的 位 置 (因为 它 是 共享 
的 ) ， 于 是 控制 器 必须 负责 提供 自用 的 工作 队列 及 重 斌 机制， 这 也 意 
味 着 它 的 ResourceEventHandler 程 序 只 是 将 事件 放 在 每 个 消费 者 的 
Workqueue 中 。 


.每 当 资 源 发 生变 化 时 ，ResourceEventHandler 程 序 都 会 将 一 个 键 放 
入 工作 队列 中 ， 对 于 名 称 空 间 级 别 资 源 对 象 的 相关 事件 ， 其 键 名 格式 
为 <resource_namespace>/<resource_name>， 集 群 级 别 资源 对 象 的 键 名 则 
只 包含 <resource_name>。 


目前， 工作 队列 存在 延 壕 队列 、 定 时 队列 和 速率 限制 队列 等 几 种 
= 


形 


因此 ， 自 定义 控制 器 构建 起 来 存在 一 定 的 复杂 度 。 实 践 中 ， 为 了 
便于 用 户 使 用 dlient-go 创 建 控制 器 ，Kubernetes 社 区 发 布 了 模板 类 的 项 
目 workqueue example 和 sample-controller， 它 们 提供 了 一 个 自 定 义 控制 
句 项 目 应 有 的 基础 结构 。 通 常 的 做 法 是 复制 相应 的 代码 并 按 需 修改 相 
应 的 部 分 ， 例 如 ， 将 syncHandler 修 改 为 自 定 义 资源 类 型 业务 处 理 逻 辑 
等 ， 而 后 借助 于 code-generator 项 目 用 脚本 完成 相应 的 组 件 ， 如 typed 
clients、informers 等 。 虽 然 好 过 从 零 构 建 自 定义 控制 器 的 代码 ， 但 这 类 
方式 总 觉得 有 些 不 趁 手 和 美中不足 。 


好 在 ， 现 在 已 经 有 了 几 类 更 加 成 熟 、 更 易 上 手 的 工具 可 用 ， 它 们 
其 至 已 经 可 以 被 视 作 开发 CRD 和 控制 絮 的 SDK 或 框架 ， 其 中 ， 主 流 的 
项 目 主 要 有 Kubebuilder 、Operator SDK 和 Metacontroller 三 个 。 
Kubebuilder 主 要 由 Google 的 工程 师 Phillip Wittrock 创 立 ， 但 目前 归属 于 
SIG API Machinery， 有 较 完 善 的 在 线 文档 。Operator SDK 是 CoreOS 发 
布 的 开源 项 目 ， 是 Operator Framework 的 一 个 子 集 ， 其 出 现时 间 略 早 ， 
社区 接受 度 较 高 ， 以 致 很 多 人 干脆 就 把 自 定 义 控制 器 与 Operator 当 作 同 
一 事物 不 加 区 分 地 使 用 ， 目 前 已 经 有 etcd、Prometheus、Rook 和 Vault 儿 
个 成 熟 的 Operator 可 用 。Metacontroller 由 GCP 发 布 ， 与 前 两 者 的 区 别 较 


大 ， 它 将 控制 器 模式 直接 委托 给 Metacontroller 框 架 ， 并 调用 用 户 提 供 
的 WebHook 实 现 模 式 的 处 理 功 能 ， 支 持 任何 编程 语言 开发 ， 接 收 并 返 
回 JSON 格 式 的 序列 化 数据 。 


限于 篇 幅 ， 这 里 就 不 再 介绍 它们 各 目的 具体 用 法 了 ， 对 目 定 义 控 
制 顷 有 兴趣 的 读者 可 参考 相关 项 目的 文档 进行 学 习 。 为 外 ， 有 兴趣 测 
试 CRD 太 目 定 义 控制 右 的 读者 也 可 以 参考 GitHub 上 的 项 目 
nikhita/custom-database-controller， 项 目地 址 为 
https://github.com/nikhita/custom-database-controller 。 


13.2” 自 定义 API Server 


扩展 Kubernetes 系 统 API 接 口 的 男 一 种 常用 办 法 是 使 用 自 定义 的 
API Server。 相 较 于 CRD 来 说 ， 使 用 上 自 定 义 API Server 更 加 灵活 ， 例 如 
可 以 自 定 义 资源 类 型 和 子 资源 、 目 定义 验证 及 其 他 逻辑 ， 甚 至 于 在 
Kubernetes API Server 中 实现 的 任何 功能 也 都 能 在 自 定义 API Server 中 
实现 。 


13.2.1 目 定 义 API Server 概 述 


自 定 义 API Server 完 全 可 以 独立 运行 并 能 够 被 客户 端 直接 访问 ， 但 
最 方便 的 方式 是 将 它们 与 主 API Server (kube-apiserver) 聚合 在 一 起 使 
用 ， 这 样 不 仅 可 以 使 得 集群 中 的 多 个 API Server 看 起 来 好 像 是 由 单个 服 
务 器 提供 服务 ， 集 群 组 件 和 kubectl 等 客户 端 可 不 经 修改 地 继续 正常 通 
信 ， 而 且 也 无 须 特 殊 逻 辑 来 发 现 不 同 的 API Server 等 操作 。 在 kube- 
apiserver 中 ， 用 于 聚合 自 定 义 API Server 的 组 件 是 kube-aggregator， 它 目 
Kubernetes 1.7 版 本 引入 ， 并 内 建 于 主 API Server 之 中 作为 其 进程 的 一 部 
分 来 运行 ， 如 图 13-4 所 示 。 


kube-apiserver Custom APIServer 1 


etcd 


Core Resources i kube-aggregator 加 
(Pods, Services, …) (CRD) (APlService) 人 


rm 


图 13-4 自 定 义 API 服 务 器 及 APIService 资 源 


在 使 用 自 定义 API Server 中 的 扩展 资源 之 前 ， 管 理 员 需要 在 主 API 
Server 上 添加 一 个 相应 的 APIService 资 源 对 象 ， 将 自 定 义 API Server 注 册 
到 kube-aggregator 之 上 ， 以 完成 聚合 操作 。 一 个 特定 的 APIService 对 象 
可 用 于 在 主 API Server 上 注册 一 个 URL 路 径 ， 

如 /apis/auth.ilinux.io/vlbetal/， 从 而 使 得 kube-aggregator 将 发 往 这 个 路 径 

的 请 求 代理 至 相应 的 自 定 义 API Server。 每 个 APIService 对 应 于 一 个 API 

0 不 同 版 本 的 单个 API 可 以 由 不 同 的 APIService 对 象 支持 ， 如 
13-5 所 不 。 


kube-ageregator 


ET Wl oe clusterilinux.io Group 


auth.ilinux.10-vlbetal 
<APIService> 


cluster.ilinux.10-vlbeta2 
<APIService> 


auth.ilinux.10-vlalpha2 
<APlIService> 


auth.ilinux.10 


auth.ilinux.i0 


auth.ilinux.10 


Custom API server 1 Custom API server 2 Custom API server 1 


图 13-5 “Kubernetes 聚 合 层 及 其 聚合 方式 


相对 于 CRD 和 目 定 义 控制 絮 来 说 ， 开 发 目 定 义 API Server 要 复杂 得 
多 ，Kubernetes 为 此 也 提供 了 专用 的 构建 聚合 API Server 的 通用 库 ， 项 
目 名 称 就 叫 作 apiserver。apiserver 开 发 库 包 含 了 用 于 创建 Kubernetes 聚 合 
服务 器 的 基础 代码 ， 其 中 包含 委派 的 authentication 和 authorization， 以 
及 kubectl 兼 容 的 发 现 机 制 、 可 选 的 许可 控制 链 (admission chain) 和 版 
本 化 类 型 (versioned type) 等 ， 同 时 ， 它 还 有 一 个 示例 性 的 项 目的 
sample-apiserver 可 用 作 开 发 模板 。 不 过 ， 目 前 最 好 的 实践 方式 是 借助 于 
专用 于 构建 聚合 服务 器 的 项 目 apiserver-builder 进 行 开发 ， 它 提供 了 基于 
apiserver 代 码 构建 原生 Kubernetes 扩 展 资源 的 开发 库 和 开发 工具 的 集 


口 


但 创建 自 定义 API Server 需 要 编写 大 量 的 代码 ， 而 且 每 个 自 定 义 的 
API Server 都 需要 自行 管理 所 使 用 的 存储 系统 ， 它 们 可 使 用 自 有 的 etcd 
存储 服务 ， 也 可 通过 CRD 将 资源 数据 存储 于 主 API Server 的 存储 系统 
中 ,但 此 场景 需要 事先 创建 依赖 到 的 所 有 自 定义 资源 。 除 非特 别 需 要 
创建 自 定 义 的 API Server， 否 则 还 是 建议 读者 选择 使 用 Kubebuilder 直 接 
基于 CRD 和 目 定义 控制 怖 进行 系统 扩展 。 


13.2.2 ”APIService 对 象 


APIService 资 源 类 型 的 最 初 设 计 日 标 是 用 于 将 庞大 的 主 API Server 
分 解 成 多 个 小 型 但 彼此 独立 的 API Server， 但 它 也 支持 将 任何 遵循 
Kubernetes API 设 计 规 范 的 自 定 义 API Server 聚 合 进 主 API Server 中 。 


下 面 的 配置 清单 示例 取 自 sample-apiserver 项 目 ， 它 定义 了 一 个 名 
为 v2betal.auth.ilinux.io 的 APIService 对 象 ， 用 于 将 default 和 名 称 空间 中 名 
为 auth-api 的 Service 对 象 后 端的 自 定 义 API Server 聚 合 进 主 API Server 


apiVersion: apiregistration.k8s.io/vibetali 
kind: APIService 
metadata: 
name: v2betal.auth.ilinux.io 
spec: 
insecureSkipTLSVerify: true 
group: auth.ilinux.io 
groupPriorityMinimum: 1000 
versionpPriority: 15 
service: 
name: auth-api 
namespace: default 
version: V2betal 


定义 一 个 APIService 对 象 时 ， 其 Spec 航 套 使 用 的 字段 包括 如 下 这 
些 字段 。 
“group<string>: 注册 使 用 的 API 群 组 名 称 。 


.groupPriorityMinimum<integer>: API 群 组 的 最 低 优先 级 ， 较 高 优 
移 级 的 群 组 将 优先 被 客户 端 使 用 ;数值 越 大 优选 级 越 高 ， 数 值 相 同时 
则 按 名 称 字 符 进 行 排序 。 


:Version<string>: 注册 的 API 群 组 的 版 本 。 


versionPriority<integer>: 当前 版 本 在 其 所 属 的 API 群 组 内 的 优先 
级 ;必须 使 用 正 整 数 数值 ， 数 值 越 大 优先 级 越 高 ， 数 值 相 同时 则 按 名 
称 字 符 进 行 排序 。 


“service<Object>: 目 定 义 API Server 相 关 的 Service 对 象 ， 是 真正 提 
供 API 服 务 的 后 端 ， 它 必须 通过 443 端 口 进行 通信 。 


-caBundle<string>: PEM 编 码 的 CA 打包 信息 ， 用 于 验证 API 
service 的 服务 证 书 。 


.insecureSkipTLSVerify<boolean>: 与 此 服务 通信 时 是 否 禁 止 TLS 
证 书 认证 。 


APIService 仅 用 于 将 API Server 进 行 聚 合 ， 真 正 提供 服务 的 是 相应 
的 外 部 API Server， 这 个 自 定 义 服务 器 通常 应 该 以 Pod 的 形式 托管 运行 
于 当前 Kubernetes 集 群 之 上 。 于 是 ， 在 Kubernetes 集 群 上 部 署 使 用 自 定 
义 API Server 主 要 由 两 步 组 成 ， 首 先 需 要 将 自 定 义 API Server 以 Pod 形 式 
运行 于 集群 之 上 并 为 其 创建 Service 对 象 ， 而 后 创建 一 个 专用 的 
APIService 对 象 与 主 API Server 完 成 聚合 。Kubernetes 系 统 的 系统 资源 
指标 API 束 由 metrics-server 项 目 提供 ， 该 项 目 基于 metrics-server 提 供 了 
一 个 扩展 的 API， 并 通过 API 群 组 metrics.k8s.io 将 其 完成 聚合 ， 后 文中 
资源 指标 及 监控 相关 的 章 忆 将 讲述 相关 的 部 署 及 使 用 方法 。 


13.3 ”Kubernetes 集 群 高 可 用 


Kubernetes 具 有 上 自 傅 能力， 当 它 跟踪 到 某 工作 节点 发 生 故 障 时 ， 欣 
制 平面 可 以 将 离线 节点 上 的 Pod 对 象 重 新 编排 至 其 他 可 用 的 工作 节点 上 
运行 ， 因 此 ， 更 多 的 工作 蔬 点 也 就 意味 着 更 好 的 容错 能 力 ， 因 为 它 使 
得 Kubernetes 在 实现 工作 节点 故障 转移 时 拥有 更 加 灵活 的 自由 度 。 而 当 
管理 员 检 测 到 集群 负载 过 重 或 无 法 容纳 其 更 多 的 Pod 对 象 时 ， 通 常 需要 
手动 将 世上 点 添加 到 集群 ， 其 过 程 略为 烦琐 ，Kubernetes cluster-autoscaler 
还 为 集群 提供 了 规模 按 需 上 自动 缩放 的 能 力 。 


然而 ， 添 加 更 多 的 工作 节点 并 不 能 使 集群 适应 各 种 故障 ， 例 如 ， 

若 主 API 服 务 器 出 现 故 障 (由 于 其 主机 出 现 故 障 或 网 络 分 区 将 其 从 集群 
中 隔离 ) ， 则 其 将 无 法 再 跟踪 和 控制 集群 。 因 此 ， 还 需要 见 余 控制 平 
面 的 各 组 件 以 实现 主 和 点 的 服务 高 可 用 性 。 基 于 元 余数 量 的 不 同 ， 控 
制 平面 能 容忍 一 个 甚至 是 多 个 节点 的 故障 。 一 般 来 说 ， 高 可 用 控制 平 
面 至 少 需要 三 个 Master 闻 点 来 承受 最 多 一 个 Master 节 点 的 丢失 ， 才 能 保 
证 等 竺 状态 的 Master 节 点 能 够 保持 半数 以 上 ， 以 满足 节点 选举 时 的 法 定 
票数 。 一 个 最 小 化 的 Master 节 点 高 可 用 架构 如 图 13-6 所 示 。 
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图 13-6 ”最 小 化 Master 节 点 高 可 用 架构 


Kubernetes 组 件 中 仪 etcd 需 要 复杂 人 逻辑 完成 集群 功能 ， 其 他 组 件 间 
的 松 耘 合 特性 使 得 系统 能 够 通过 多 种 方式 实现 Master 节 点 的 高 可 用 性 ， 
和 
， 上 其 体 如 下 。 


.利用 etcd 自 身 提供 的 分 布 式 存储 集群 为 Kubernetes 构 建 一 个 可 靠 的 
存储 层 。 


-将 无 状态 的 apiserver 运 行为 多 副本 ， 并 在 其 二 端 使 用 负载 均衡 器 
调度 请 求 ， 需 要 注意 的 是 ， 负 载 均衡 器 本 身 也 需要 是 高 可 用 的 。 


:多 副本 的 控制 器 管理 右 ， 通 过 其 自 带 的 leader 选 举 功 能 (--leader- 
election) 选举 出 主角 色 ， 余 下 的 副本 在 主角 色 发 生 故 障 时 自动 启动 新 
一 轮 的 选举 操作 。 


:多 副本 的 调度 器 ， 通 过 其 自 市 的 leader 选 举 功 能 (--leader- 
election) 选举 出 主角 色 ， 余 下 的 副本 在 主角 色 发 生 故 障 时 自动 启动 新 
一 轮 的 选举 操作 。 


13.3.1 ”etcd 高 可 用 


分 布 式 服务 之 间 进 行 可 靠 、 融 效 协作 的 关键 前 提 十 有 一 个 可 信 的 
数据 存储 和 共享 机 制 ，etcd 项 目 正 是 致力 于 此 目的 构建 的 分 布 式 数据 
存储 系统 ， 它 以 键 值 格式 组 织 数 据 ， 主 要 用 于 配置 共 译 和 服务 发 现 ， 
也 支持 实现 分 布 式 锁 、 集 群 监控 和 ]eader 选 举 等 功能 。 


etcd 基 于 Go 语言 开发 ， 内 部 采用 raft 协 议 作 为 共识 算法 进行 分 布 式 
协作 ， 将 数据 同步 存储 在 多 个 独立 的 服务 实例 上 以 提高 数据 的 可 靠 
性 ， 从 而 避免 了 单 点 故障 所 导致 的 数据 丢失 。Raft 协 议 通过 选举 出 的 
leader 六 点 来 实现 数据 的 一 臻 性， 由 leader 广 点 负责 所 有 的 写 入 请 求 并 
同步 给 集群 中 的 所 有 节点 ， 在 取决 半数 以 上 follower 闻 点 的 确认 后 予以 
持久 存储 。 这 种 需要 半数 以 上 市 点 投票 的 机 制 要 求 集群 数量 最 好 是 奇 
数 个 节点 ， 推 荐 的 数量 为 3 个 、5 个 或 7 个 。etcd 集 群 的 建立 有 三 种 方 
式 ， 具 体 如 下 。 


-静态 集群 : 事先 规划 并 提供 所 有 市 后 的 固定 IP 地 址 以 组 建 集群 ， 
仅 适 合 于 能 够 为 节点 分 配 静 态 IP 地 址 的 网 络 环境 ， 好 处 是 它 不 依赖 于 
任何 外 部 服务 。 


基于 etcd 发 现 服务 构建 集群 ， 通 过 一 个 事先 存在 的 etcd 集 群 进行 
服务 发 现 来 组 建新 集群 ， 文 持 集群 的 动态 构建 ， 它 依赖 于 一 个 现存 可 
用 的 etcd 服 务 。 


基于 DNS 的 服务 资源 记录 构建 集群 ， 通 过 在 DNS 服 务 上 的 某 域名 
下 为 每 个 节 护 创建 一 条 SRV 记 录 ， 而 后 基于 此 域名 进行 服务 发 现 来 动 
态 组 建新 集群 ， 它 依赖 于 DNS 服务 及 事 允 管理 妥当 的 货源 记录 。 


一 般 说 来 ， 对 于 etcd 分 布 式 存储 集群 来 说 ， 三 市 点 集群 可 容错 一 
个 而 点， 五 玉 扩 集群 可 容错 两 个 证 点 ， 七 节 扩 集群 可 容错 三 个 方太 ， 
依次 类 推 ， 但 通 前 来 说 ， 多 于 七 个 节点 的 集群 规模 是 没有 必要 的 ， 而 
且 对 系统 性 能 也 会 产生 负面 影响 。 


13.3.2 ”Controller Manager 和 Scheduler 高 可 用 


Controller Manager 通 过 监控 API Server 上 的 资源 状态 变动 并 按 需 分 
别 执行 相应 的 操作 ， 于 是 ， 多 实例 运行 的 kube-controller-manager 进 程 
可 能 会 导致 同一 操作 行为 被 每 一 个 实例 分 别 执行 一 次 ， 例 如 ， 某 一 
Pod 对 和 象 创 建 的 请 求 被 3 个 控制 器 实例 分 别 执行 一 次 进而 创建 出 一 个 
Pod 对 象 副本 来 。 因 此 ， 在 某 一 时 刻 ， 仅 能 有 一 个 kube-controller- 
manager 实 例 处 于 正常 工作 状态 ， 余 下 的 均 处 于 备用 状态 ,或 者 称 为 等 


待 状 态 。 


多 个 kube-controller-manager 实 例 要 同时 启用 “--leader-elect=true” 选 
项 以 目 动 实 现 leader 选 举 ， 选 举 过 程 完成 后 ， 仅 leader 实 例 处 于 活动 状 
态 ， 余 下 的 其 他 实例 均 转 入 等 竺 模式 ， 它 们 会 在 探测 到 leader 故 障 时 进 
行 狐 一 轮 的 选举 。 与 etcd 集 群 基于 raft 夫 议 进 行 leader 选 举 不 同 的 是 ， 
kube-controller-manager 集 群 各 目的 选举 操作 仅 是 通过 在 kube-system 和 名 
称 空间 中 创建 一 个 与 程序 同名 的 Endpoints 资 源 对 象 来 实现 ; 


~]$ kubect1 get endpoints -n kube-system 


NAME ENDPOINTS AGE 
kube-controller-manager <none> 13h 
kube-scheduler <none> 13h 


这 种 leader 选 举 操作 是 分 布 式 锁 机 制 的 一 种 应 用 ， 它 通过 创建 和 维 
护 Kubernetes 资 源 对 象 来 维护 锁 状 态 ， 目 前 Kubernetes 文 持 ConfigMap 
和 Endpoints 两 种 类 型 的 资源 锁 。 和 初始 状态 上 时， 各 kube-controller- 
manager 实 例 通 过 竞争 的 方式 去 抢占 指定 的 Endpoints 资 源 锁 。 胜 利 者 将 
成 为 leader， 它 通过 更 新 相应 的 Endpoints 资 源 的 注解 control- 
plane.alpha.kubernetes.io/leader 中 的 “holderIdentity” 为 其 节点 名 称 ， 从 而 
将 自己 设置 为 锁 的 持 有 者 ， 并 基于 周期 性 更 新 同一 注解 中 
的 “renewTime” 以 声明 目 己 对 锁 资 源 的 持 有 状态 从 而 避免 等 待 状态 的 实 
例 进 行 争 抢 。 于 是 ， 一 旦 某 leader 不 再 更 新 renewTime 了 ， 等 得 状态 的 
各 实例 就 将 一 哄 而 上 进行 新 一 轮 的 竞争 。 


~]$ kubectl1 describe endpoints kube-controller-manager -n kube-system 
Name : kube-controller-manager 
Namespace: kube-system 


Labels: <none> 
Annotations: control-plane.alpha.kubernetes.io/leader= 
{"holderIdentity":"master1. 
ilinux.io_846a3ce4-b0b2-11e8-9a23- 
©00505628fa03","leaseDurationSeconds":15,"acquireTime": 
"2018-09-05T02:22:542Z", "renewTime":"2018-09- 
05T0O2:40:552Z","leaderTransitions":1}" 
Subsets: 
Events: 
Type Reason Age From Message 


Normal LeaderElection 13h kube-controller-manager 
master0.ilinux.io_e8fca6fc- 
bo049-11e8-a247-000c29ab0f5b became leader 
Normal LeaderElection 5m kube-controller-manager master1.ilinux.io 846- 
a3ce4-b0b2-11e8-9a23-00505628fa03 became leader 


kube-scheduler 的 实现 方式 与 此 类 似 ， 只 不 过 它 使 用 的 是 上 自己 专用 
的 Endpoints 资 源 kube-scheduler 。 


名 提示 “基于 kubeadm 部 署 高 可 用 集群 的 方式 可 参考 文档 
https://kubernetes.io/docs/setup/independent/high-availability/ 给 出 的 步骤 
米 进 行 ” 


13.4 ”Kubernetes 的 部 署 模式 


Kubernetes 在 容 俐 生态 系统 的 快速 增长 过 程 中 形成 了 多 种 部 署 模 
式 ， 包 括 上 自助 式 、 目 托管 式 和 完全 目 动 化 等 多 种 管理 形式 的 集群 。 无 
论 部 署 方式 如 何 ， 开 发 人 员 和 运营 团队 都 要 遵循 标准 化 、 一 人 致 的 工作 
a 生命 周期 ， 这 也 恰 是 Kubernetes 的 关键 
WE 


实践 中 ，Kubernetes 的 客户 可 以 使 用 各 种 各 样 的 部 署 模 型 ， 包 括 
对 开发 人 员 友 好 的 PaaSs 模 型 以 及 高 度 目 定义 的 运行 于 裸 服 务 器 的 部 署 
模型 ， 等 等 ， 其 中 的 每 种 模式 都 有 其 优 缺 点 。 通 常 ， 将 容器 部 署 到 本 
地 服务 颖 时， 数据 的 持久 存储 是 最 大 的 挑战 ， 而 对 于 那些 部 署 到 云 环 
境 的 模型 来 说 ， 引 用 监视 和 日 志 记 录 则 是 其 最 大 的 挑战 。 另 外 ， 安 全 
性 是 任何 Kubernetes 部 署 模型 的 核心 因素 ， 任 何 部 署 操 作 从 设计 时 就 
应 该 充分 考虑 到 其 安全 性 。 


本 六 主要 手 述 Kubernetes 系 统 较 为 常用 的 部 署 模 型 ， 以 帮助 读者 
理解 其 部 署 选 项 ， 与 每 个 选项 相关 的 挑战 和 考虑 因素， 以 及 在 其 中 运 
行 生产 型 工作 人 负载 的 管理 模型 。 


13.4.1 关键 组 件 


生产 可 用 的 部 署 方案 中 ， 除 了 Kubernetes 之 外 ， 还 有 多 咎 对 生 ) 玉 
群 来 说 至 关 重 要 的 组 件 ， 如 镜像 仓库 、 监 探 系统、 日 志 系 统 等 ， 如 图 
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图 13-7 ”Kubermetes 集 群 的 关键 组 件 


1) 核心 基础 架构 : 此 为 Kubernetes 集 群 的 基础 设施 组 件 ， 用 于 提 
供 支 持 容 器 化 工作 负载 的 计算 、 网 络 及 存储 相关 的 底层 部 件 ， 它 们 可 
能 是 物理 服务 器 、 虚 拟 化 数据 中 心 、IaaS 类 型 的 私有 去 或 公有 云 。 


2) 著 加 网 络 : Kubernetes 基 于 SDN (Software-Defined 
Networking) 提供 的 网 络 环境 实现 内 部 通信 ， 它 将 用 于 确保 集群 的 所 有 
内 部 组 件 都 能 够 正常 通信 ， 可 以 选用 的 项 目 包含 诸如 Calico、Flannel、 
Romana 和 Weave Net 等 ， 这 在 前 面 的 章节 中 已 经 有 过 详细 的 讲解 。 


3) 存储 系统 : 运行 有 状态 的 工作 负载 《如 数据 库 ) 时 ， 持 久 化 数 
据 存储 是 必 备 的 组 件 。SDS (Software-Defined Storage) 层 即 作为 持久 
存储 卷 又 露 给 容 希 ， 分 布 式 存储 软件 如 GlusterFS、 网 络 文件 系统 
(NFS) 和 块 级 别 存 储 卷 \(RBD 等 ) 是 首选 。 


4) Kubernetes 集 群 ， 由 控制 平面 Master 节 点 、 分 布 式 键 值 存储 系统 
etcd 和 工作 节点 组 成 。 主 节点 负责 工作 负载 的 调度 和 编排 ， 主 要 由 API 
服务 器 、 控 制 器 管理 器 和 调度 器 组 成 。 它 们 是 Kubernetes 集 群 的 控制 中 
心 ， 生 产 环境 中 需要 宛 余 化 配置 以 确保 服务 的 可 用 性 。etcd 存 储 系统 负 
责 维 护 集群 和 工作 负载 的 当前 状态 ， 鉴 于 其 重要 性 通常 需要 为 其 配置 
分 布 式 环境 以 实现 见 余 和 高 可 用 性 。 各 工作 世 点 负责 运行 工作 负载 ， 
在 云 计 算 环 境 中 此 部 分 可 由 Cluster AutoScaler 实 现 弹 性 伸缩 。 


容器 化 工作 负载 : 于 Kubernetes 集 群 内 部 署 的 应 用 程序 ， 其 中 
分 有 可 能 需要 暴露 给 集群 外 部 的 客户 端 程序 。 


6) 供应 和 配置 管理 : 安装 和 配置 Kubernetes 集 群 与 部 署 高 度 可 用 
的 关键 型 分 布 式 应 用 程序 并 无 太 大 区 别 。 为 了 确保 一 致 性 和 可 重复 
性 ， 通 单 应 该 依赖 于 工具 链 的 实现 ， 类 似 Ansible、Chef、Puppet、 
Terraform 和 其 他 目 动 化 工具 。 这 些 工具 使 得 升级 、 修 补 和 维护 
Kubernetes 基 础 染 构 变 得 更 加 容易 。 


7) 镜像 仓库 : 运行 容器 化 应 用 程序 时 ，Kubernetes 世 点 需要 事先 
从 镜像 仓库 中 提取 相应 的 容 右 镜像 。 
像 的 环境 中 ， 应 用 程序 将 自动 升级 为 最 新 版 本 的 镜像 。 为 了 减少 延 
并 提高 安全 性 ， 镜 像 应 该 存储 在 托管 于 集群 之 上 的 仓库 服务 中 。 


8) 日 志 记 录 和 监控 : 分 布 式 应 用 程序 会 生成 大 量 日 志 ， 
Kubernetes 也 不 例外 。 集 群 中 的 每 个 组 件 (包括 已 部 署 的 应 用 程序 ) 都 
会 生成 需要 捕获 和 人 处理 的 日 志 ， 它 们 对 故障 排查 和 监视 群集 活动 有 着 
不 可 替代 的 作用 。 日 志 与 监控 工具 结合 使 用 ， 有 助 于 深入 了 解 集 群 的 
运行 状态 ， 常 用 的 实现 有 如 Plastic Stack、Grafana 和 Prometheus 等 。 该 
层 是 生产 部 署 的 重要 组 成 部 分 


9) 负载 均衡 器 : Kubernetes 集 群 有 两 处 位 置 依赖 于 负载 均衡 器 ， 
它们 分 别 是 API 服 务 器 和 公共 类 型 的 容器 化 应 用 。 配 置 了 高 可 用 服务 的 
Master 节 点 上 ，API 服 务 器 经 负载 均衡 器 调度 以 承载 更 多 的 用 户 请 求 ， 
而 提供 公共 服务 的 应 用 程序 运行 于 多 个 Pod 对 象 并 向 集群 外 部 暴露 时 也 
需要 负载 均衡 器 。 


10) 工件 仓库 : 工件 仓库 用 于 维护 属于 应 用 程序 的 资产 ， 尤 其 是 
了 着 分 布 式 应 用 程序 复杂 性 的 增长 ， 需 要 管理 的 程序 资产 包括 各 种 配 


置 设 定 、 依 赖 项 、 软 件 包 、 脚 本 ， 甚 至 是 二 进 制 文 件 。 在 某 些 情况 
下 ， 工 件 仓库 本 身长 至 也 具有 镜像 仓库 的 功能 。 


11) 构建 和 发 布 管理 : 随 着 持续 集成 和 持续 交付 成 为 应 用 程序 生 
命 周 期 管理 (ALM) 的 首选 机 制 ， 构 建 和 发 布 自动 化 正在 成 为 开 组 织 
核心 文化 ， 实 现 此 类 功能 的 目 动 化 工具 通过 高 效 的 流水 线 来 连接 源 代 
码 管理 系统 和 生产 环境 。 


13.4.2 ”常见 的 部 署 模式 


Kubernetes 是 近来 最 为 成 功 的 开源 项 目 之 一 ， 在 CNCE 的 主导 下 ， 
它 得 到 了 来 自 于 CoreOS、Google、 华 为 、 IBM、RedHat 和 中 兴 通 讯 等 
公司 程序 员 的 积极 贡献 ， 源 代码 质量 较 高 且 经 过 了 社区 的 严格 评估 ， 
托管 于 GitHub 之 上 的 代码 仓库 中 的 主干 代码 可 直接 用 于 部 署 生 产 环 
境 。 不 过 ， 据 CNCEF 于 2017 年 秋季 的 调查 显示 ， 实 施 的 复杂 性 仍 是 许多 
组 织 不 使 用 Kubernetes 的 主要 原因 之 一 。 


幸运 的 是 ，Kubernetes 项 目 在 日 渐 成 熟 的 过 程 中 ， 社 区 为 系统 的 安 
装 简化 也 正在 倾 力 而 为 。 尽 管 该 软件 的 初始 版 本 安装 起 来 依然 稍 显 复 
杂 ， 但 借助 于 kubeadm 之 类 的 工具 已 然 能 够 使 得 普通 的 系统 管理 员 也 可 
以 较为 轻松 地 部 团 Kubernetes， 本 书 使 用 的 也 正 是 这 种 部 署 方式 。 田 
外 ， 诸 如 Cloud Foundry Container Runtime 、Canonical conjure-up 和 kops 
ek 性 也 使 得 Kubernetes 在 数据 中 心 和 公有 云 环 境 中 的 部 团 变 
得 更 加 简单 。 


于 是 ， 目 定义 或 目 主 托管 Kubernetes 部 署 的 模式 正在 受到 越 来 越 多 
人 的 关注 ， 基 于 此 种 方式 ， 用 户 可 以 在 物理 服务 器 、 虚 拟 机 和 云 计 算 
We 其 配置 方式 和 部 署 体 验 据 所 用 工具 的 不 同 而 有 


目 定义 的 部 车 模 式 为 用 户 的 终极 部 署 机 制 ， 他 们 可 以 从 众多 的 目 
标 部 署 环境 、 机 顺 配 置 、 操 作 系统 、 人 存储 后 端 、 网 络 插件 和 高 可 用 性 
配置 中 进行 选择 。 当 然 ， 在 提供 多 样 性 选择 和 控制 的 同时 ， 维 护 集群 
的 责任 将 全 部 维系 于 用 户 自身 。 因 此 ， 此 种 模式 中 ， 用 户 需 要 为 生产 
群集 握 供 整个 组 件 堆栈 ， 包 括 从 底层 计算 、 网 络 和 存储 资源 到 镜像 仓 
库 等 的 安装 、 配 置 和 管理 。 当 然 ， 在 公共 云 环 境 中 ， 一 些 资 源 〈 如 虚 
拟 机 和 块 存 储 设备 ) 则 由 IaaS 服 务 商 和 常理 。 


在 操作 系统 、 存 储 后 端 和 车 加 网 络 方面 需要 高 度 自 定 义 的 组 织 通 
常会 选择 目 定 义 或 目 托管 部 署 ， 毕 况 此 方法 还 提供 了 一 些 其 他 部 署 模 
式 中 可 能 无 法 提供 的 高 级 功能 。 自 定义 部 署 是 最 廉价 的 选择 ， 因 为 客 
户 只 需要 投资 基础 架构 ， 用 到 的 几乎 所 有 的 工具 都 是 开源 的 ， 都 可 以 
2 但 是 组 织 必须 考虑 维护 基础 设施 所 涉及 的 人 员 和 文 
寺 成 本 。 


而 那些 希望 在 数据 中 心 或 公有 云 环 境 中 运行 Kubernetes 而 无 须 安装 
或 维护 集群 的 用 户 可 选择 托管 的 Kubernetes 集 群 产品 ， 提 供 托 管 
Kubernetes 服 务 的 供应 商 则 辐 用 户 收 取 集 群 的 管理 和 维护 费用 ， 为 此 用 
户 将 不 得 不 花费 核心 基础 设施 以 及 订购 获得 许可 费用 。 托 管 的 
Kubernetes 平 台 提 供 了 两 全 其 美的 功能 : 基础 设施 的 选择 与 免 维 护 集群 
的 结合 。 不 有 具备 安装 、 配 置 和 管理 大 规模 部 署 所 需 技 能 的 组 织 可 以 选 
择 托 管 的 Kubernetes 平 台 ， 如 图 13-8 所 示 的 带 有 独立 边框 的 组 件 部 分 将 
由 服务 商 负责 。 
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图 13-8 托管 的 Kubernetes 集 群 环境 


由 于 平台 供应 商 可 以 远程 管理 集群 ， 因 此 用 户 可 以 专注 于 应 用 程 
序 的 开发 ， 而 不 是 维护 容器 基础 架构 。 不 过 ,与 自 托管 部 署 相 比 ， 托 
管 式 Kubernetes 产 品 更 昂贵 ， 毕 竟 组 织 将 不 得 不 考虑 基础 架构 成 本 以 及 
集群 管理 成 本 ， 好 在 管理 Kubernetes 平 台 的 定期 升级 、 人 修补、 安全 和 监 
探 服 务 的 优势 可 以 在 长 期 预算 范围 内 抵消 一 部 分 成 本 。 此 类 的 常见 解 
决 方案 有 IBM Cloud Private、Platform9 和 Tectonic 等 。 


另外 ， 早 期 的 Paas 实 现 通常 是 基于 隔离 应 用 程序 上 下 文 的 专 有 技 
术 ， 而 当 Docker 成 为 开源 集装箱 化 拉 术 时 ，PaaS 服 务 商 借助 于 容 磊 取 
代 了 专 有 的 执行 环境 。 如 今 ， 大 多 数 的 Paas 产 品 都 在 容器 上 进行 构 
建 。 虽 然 打 包 成 为 容器 的 程序 代码 仍然 运行 在 虚拟 机 或 物理 服务 器 
上 ， 但 Kubernetes 已 成 为 管理 容器 的 事实 上 的 编排 引 警 ， 那 些 传统 的 


Provisioning & 
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PaaS 完 全 可 以 切换 为 构建 在 Kubernetes 的 基础 上 ， 提 供 端 到 端的 应 用 程 
序 的 生命 周期 管理 服务 。 


PaaS 可 以 部 署 在 公有 云 环境 中 或 企业 数据 中 心 内 部 ， 很 多 大 型 组 
织 正在 采用 PaaS 来 运行 内 部 应 用 程序 以 及 面 辣 客 户 的 应 用 程序 ， 他 们 
希望 开发 团队 获得 一 致 的 体验 ， 而 不 考虑 部 署 目 标 是 私有 云 还 是 公共 
云 环境 。 基 于 Kubernetes 的 PaaS 产 品 通过 一 致 的 工作 流程 和 部 署 模式 辐 
企业 提供 了 这 一 保证 ， 甚 至 ， 在 许多 情况 下 ， 开 发 人 员 甚至 不 需要 知 
道 他 们 的 代码 将 在 Kubernetes 集 群 内 运行 。 这 就 意味 着 ，PaaS 层 抽象 了 
Kubernetes 的 底层 细节 ， 并 且 只 公开 了 开发 人 员 理解 的 API 端 点 。 

事实 上 ， 当 DevOps 工 具 部 署 于 Kubernetes 业 务 流程 之 上 时 ， 它 就 扩 
展 成 了 一 个 容器 类 型 的 PaaS 平 台 。 开 发 人 员 不 必 人 处 理 打 包容 器 的 代 
码 ， 因 为 平台 包含 将 源 代码 转换 为 镜像 的 工具 ， 并 且 平 台 会 处 理 无 状 
态 服 务 和 有 状态 服务 之 间 的 连接 ， 开 发 人 员 也 无 顷 了 解 如 何 配置 服务 
发 现 机 制 来 发 现 内 部 和 外 部 服务 ， 如 图 13-9 所 示 。 不 过 ， 尽 管 PaaS 降 低 
了 复杂 性 ， 但 灵活 性 有 所 欠缺。 
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图 13-9 ”基于 Kubernetes 的 PaaS 


目 托管 和 托管 的 Kubernetes 集 群 ， 其 目标 是 管理 员 和 DevOps 团 队 ， 
而 基于 Kubernetes 的 PaaS 则 是 为 开发 人 员 所 设计 的 ， 他 们 可 以 将 源 代码 
直接 应 用 于 平台 上 ， 而 不 是 像 Docker 镜 像 或 Kubernetes Pod 那 样 打包 的 


工件 。 他 们 不 需要 处 理 平 台 相 关 的 任何 操作 ， 而 仅 需要 关注 代码 和 应 

用 程序 生命 周期 。Kubernetes 已 经 成 为 现 如 今 PaaS 平 台 实践 的 基础 ， 

Red Hat OpenShift 和 Mesosphere DC/OS 是 著名 的 基于 Kubernetes 的 PaaS 
品 o 


最 后 ， 随 着 Kubernetes 的 成 熟 ， 其 用 例 开 始 超越 普通 的 容器 编排 服 
务 而 逐渐 被 用 于 多 种 小 众 场景 中 ， 这 包括 边缘 计算 (Edge 
Computing) 、 机 器 学 习 、 无 服务 计算 (Serverless Computing) 和 数据 
流 分 析 (Stream Analytics) 等 ， 尤 其 值得 一 提 的 是 新 近 兴 起 的 无 服务 
计算 。 目 前 ， 无 服务 计算 与 虚拟 机 和 容器 一 起 已 成 为 公有 云 提 供 商 提 
供 的 基本 计算 服务 。 不 过 ， 与 其 他 计算 服务 不 同 的 是 ， 无 服务 计算 基 
于 事件 驱动 ， 开 发 人 员 以 功能 的 形式 将 代码 搬 段 上 传 到 无 服务 器 平台 
后 ， 它 们 只 会 在 外 部 事件 触发 时 执行 ， 而 非 一 直 以 后 台 进 程 处 于 守护 
运行 状态 。AWS Lambda、Azure 玉 数 和 Google Cloud Functions 是 公有 
云 中 一 些 流行 的 无 服务 器 计算 选择 。Docker 可 用 于 无 服务 器 计算 ， 于 
是 Kubernetes 成 为 在 运行 时 管理 这 些 Docker 容 如 的 首选 项 。Apache 
OpenWhisk、Fission、Kubeless、nuclio 和 OpenFaaSs 是 基于 Kubernetes 的 
部 署 Serverless 的 项 目 。 


13.5” 容 絮 时 代 的 DevOps 概 述 


DevOps 的 理论 和 实践 起 源 于 2009 年 前 后 ， 但 最 初 应 用 的 大 趋势 不 
温 不 火 ， 直 到 容积 技术 出 现 并 迅速 流行 开 来 之 后 ，DevOps 才 日 渐 红 火 
起 来 。 冤 其 原因 ， 其 中 的 一 个 可 能 性 便 是 ， 容 闫 是 一 个 催化 剂 ， 它 让 
DevOps 文 化 的 落地 变 得 更 加 易于 实现 。 


应 用 程序 的 设计 染 构 从 单 体 架构 发 展 到 分 层 染 构 之 后 ， 各 种 分 布 
式 协 作 的 组 件 通常 会 由 不 同 的 开发 团队 来 维护 和 交付 ， 这 些 应 用 组 件 
可 能 使 用 了 不 同 的 编程 语言 ， 依 赖 于 不 同 的 开发 库 环境 及 外 部 协作 关 
系 ， 这 种 系统 以 构 部 车 和 维护 的 复杂 度 为 运 维 工 作 市 来 了 极 大 的 挑 
战 ， 这 一 点 通过 13.5 节 中 描述 的 DevOps 各 环节 层出不穷 的 可 用 工具 也 
可 见 一 班 。 如 今 ， 应 用 程序 的 分 层 碎 构 进 一 步 发 展 至 微服 务 架 构 ， 开 
发 人 员 获得 便利 的 同时 ， 运 维 工作 的 挑战 性 却 有 着 进一步 上 升 之 势 。 


容器 技术 的 出 现 使 得 运 维 工作 复杂 度 不 断 上 升 的 难题 迅速 得 以 冰 
消 瓦解 ，DevOps 在 技术 层面 的 落地 不 再 是 有 眼花 绕 乱 的 局 面 ， 它 们 被 统 
一 在 容器 镜像 制作 、 分 发 和 部 署 的 纬度 上。 通过 使 用 Dockerfile 构 建 容 
右 镜 像 ， 应 用 的 配置 和 部 署 工作 被 提前 到 了 编译 时 进行 ， 这 一 点 改变 
了 之 前 制作 好 应 用 发 布 于 不 同 的 环境 中 之 后 再 去 手动 调整 环境 变量 的 
人 ， 由 于 系统 环境 的 差异 所 造成 问题 出 现 的 可 能 性 几乎 
条 21 了 最 低 。 


13.5.1 容器 : DevOps 协 作 的 基础 


容器 技术 解决 了 不 同系 统 环境 上 应 用 程序 的 配置 和 维护 的 复杂 度 
难题 ， 从 而 使 得 开发 人 员 和 IT 运 维 人 员 能 够 更 紧密 和 更 高 效 地 协作 ， 
为 DevOps 的 快速 落地 提供 了 一 个 极 具 效用 的 突破 口 。 有 了 容器 ， 传 统 
DevOps 实 践 中 不 得 不 为 各 种 环境 中 应 用 程序 的 构建 和 释 出 进行 复杂 配 
置 的 局 面 ， 被 容器 技术 极 大 地 简化 了 。 


借助 Docker 容 器 ， 开 发 人 员 可 以 做 到 将 精力 集中 于 容器 中 内 容 的 
构建 (应 用 程序 和 服务 ， 以 及 它们 所 依赖 的 框架 和 组 件 ) 以 及 如 何 将 
容器 和 服务 协同 在 一 起 工作 之 上 。 当 然 ， 容 器 协调 的 编排 机 制 有 赖 于 
编排 工具 的 介入 。 相 对 应 地 ，IT 运 维 人 员 则 可 以 将 主要 精力 集中 于 生 
产 环 境 管理 方面 ， 例 如 基础 架构 、 系 统 扩 缩 容 、 监 控 ， 以 及 将 应 用 程 
序 正 确 交付 到 终端 用 户 等 ， 他 们 根本 无 须 关 心 容器 内 容 本 号 。 


如 图 13-10 所 示 ， 开 发 人 员 人 负责 开发 编写 容器 中 运行 的 应 用 程序 ， 
他 们 通过 Dockerfile 来 定义 应 用 程序 所 依赖 的 系统 环境 ， 以 及 将 代码 构 
建 到 容器 镜像 中 的 步 又， 并 借助 于 编排 工具 的 编排 机 制定 义 容器 的 协 
同方 式 。 遵 循 业务 环境 需求 ， 将 制作 好 的 Docker 配 置 文件 推送 至 项 目 
的 代码 仓库 中 (如 Git 仓 库 ) 即 可 进入 后 续 的 步骤 。 
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图 13-10 ”容器 模型 中 的 DevOps (来 源 : microsoft.com ) 


接 下 来 ， 在 DevOps 环 节 持 续集 成 《CI) 流水 线 从 Git 仓 库 中 获取 到 
的 Dockerfile， 结 合 从 镜像 仓库 中 拿 到 基础 镜像 自动 构建 目 定 义 的 容 回 
和 仓库 中 以 用 于 后 续 的 部 

所 站 O 


随后 ， 由 CD (持续 交付 和 技术 部 署 ) 流水 线 上 自动 完成 基础 设施 构 
建 、 环 境 设 定 、 容 器 部 署 和 监控 等 工作 ， 并 将 系统 状态 数据 不 断 地 反 
馈 至 开发 团队 。 对 于 此 环 市 来 说 ， 不 同 的 团队 的 不 同 项 目的 目 动 化 程 
度 可 能 会 有 所 不 同 ， 有 的 甚至 还 可 能 会 由 运 维 团 队 手 工 完成 。 


由 此 可 见 ， 开 发 和 运 维 两 个 团队 在 容 右 平台 的 辅助 下 得 以 完成 协 
从 而 大 大 缩短 了 软件 开发 的 生命 周期 。 开发 人 员 人 负责 维护 容器 的 
内 容 而 运 维和 人 员 则 负责 在 编排 系统 的 辅助 下 将 镜像 运行 为 一 个 个 的 
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13.5.2” 沁 型 端 到 问 容 吉 应 用 程序 生命 周期 工作 流 


图 13-11 提 供 了 更 详细 的 Docker 应 用 程序 生命 周期 的 工作 流 ， 其 着 
重 摘 述 了 DevOps 的 活动 和 资产 。 


DevOps 流 程 始 于 开发 人 员 ， 他 们 在 目 有 的 内 部 循环 中 编写 并 调试 
程序 代码 ， 而 后 将 “稳定 ”状态 的 代码 推送 至 代码 仓库 (如 Git) 中 。 提 
交 完 成 后 ， 代 码 仓库 将 触发 CI 和 工作 流 的 其 余部 分 。 


DevOps 工 作 流 不 仅仅 是 一 个 工具 集合 ， 它 更 是 一 种 软件 开发 演进 
而 来 的 文化 ， 它 是 使 得 软件 开发 更 敏捷 及 可 预测 的 人 员 、 流 程 和 相应 
的 工具 的 集成 。 于 是 ， 采 用 了 容 右 化 工作 流 的 组 织 束 需要 基于 容器 工 
作 流 来 重 构 他 们 的 组 织 及 其 工作 机 制 。 实 践 DevOps， 以 目 动 化 取代 手 
工 劳 动 从 而 大 大 提升 效率 并 降低 出 错 的 可 能 性 ， 从 而 帮助 组 织 或 企业 
内 容 更 高 效 地 协作 以 获得 更 好 的 竞争 优势 。 男 外 ， 组 织 还 可 以 结合 云 
计算 按 需 为 系统 配置 资源 ， 实 现 更 高 效 的 环境 管理 和 资源 利用 最 大 
化 ， 区 约 运 行 成 本 。 
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图 13-11 泛 型 端 到 端 容器 生命 周期 工作 流 (来 源 : microsoft.com ) 


13.5.3 ”基于 KubernetesHJDevOps 


在 DevOps 工 作 流 中 ，Kubernetes 作 为 运行 时 环境 中 的 编排 工具 ， 用 
于 容器 的 编排 运行 。 例 如 ， 如 图 13-12 所 示 的 DevOps 工 具 链 中 所 展示 的 
DevOps 工 作 流 包括 如 下 内 容 。 


1) 开发 人 员 编 写 应 用 代码 推送 至 Git 上 的 代码 仓库 ， 而 后 经 CI 工具 
链 构 建 、 测 试 后 释 出 。 


2) 开发 人 员 编 写 Dockerfile 推 送 至 Git 上 的 项 目 仓库 中 ， 而 后 基于 
释 出 的 应 用 程序 构建 Docker 镜 像 ， 并 推送 至 Docker 仓 库 


3) 开发 人 员 编 写 Kubernetes 清 单 (manifest) 或 helm charts， 而 后 
由 kube applier 应 用 (创建 或 升级 ) 至 Kubernetes 集 群 加 以 运行 。 
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图 13-12 ”基于 Kubernetes 的 DevOps 工 作 流 
kube-applier 是 一 种 服务 ， 在 集群 中 作为 Pod 运 行 ， 并 监视 Git 仓 
库 ， 通 过 将 声明 性 配置 文件 从 Git 存 储 库 应 用 到 Kubernetes 集 群 ， 实 现 持 
续 部 署 资 源 对 象 。 图 13-12 显 示 的 工作 流 中 ，Jenkins 是 整个 CICD 流 水 


线 的 Hub， 它 经 由 Git WebHook 触 发 控制 着 CI、 镜 像 构 建 、Kubernetes 
Pod 创 建 和 编排 等 一 应 操作 。 


此 种 场景 中 ，Jenkins 承 担 了 太 多 的 工作 ，CI、 镜 像 构建 、 基 础 环 
境 、 应 用 部 署 均 由 其 负责 实施 ， 每 当 有 团队 需要 做 一 个 新 的 部 署 流 水 
线 时 ， 束 会 根据 具体 需求 进行 微调 ， 必 要 时 还 得 重 写 所 有 的 脚本 ， 效 
率 略 低 。 对 于 有 研发 实力 的 组 织 ， 可 以 把 关键 的 工作 做 成 单独 的 系 
统 ， 例 如 ， 不 再 把 构建 组 件 和 部 嗜 组 件 作为 Jenkins 的 插件 ， 而 是 分 别 
做 成 独立 的 系统 。 


另外 ，DevOps 的 流程 中 需要 的 各 种 工具 链 几 乎 都 可 以 托管 于 
Kubernetes 平 台 之 上 运行 ， 包 括 Jenkins。 此 时 ， 再 加 上 Kubernetes 平 台 
支持 的 调度 、 健 康 检 查 、 日 志 、 监 控 、 安 全 、 应 用 服务 、 弹 性 扩 缩 容 
和 服务 发 现 等 功能 ， 束 是 一 个 完整 的 容器 云 平 台 。 不 过 ， 有 些 开 源 项 
目 本 吴 已 经 直接 集成 了 这 些 功能 ， 如 OpenShift 和 Tectonic 等 。 


13.6 ”本 章 小 结 


本 章 主 要 讲解 了 自 定义 资源 类 型 CRD、 自 定义 资源 对 象 、 自 定义 
控制 姻 、 目 定义 API Server 及 API 案 合 等 Kubernetes API 的 扩展 方式 ， 给 
出 了 Kubemetes 集 群 高 可 用 架构 中 控制 平面 的 实现 机 制 ， 并 说 明了 生 
产 环 境 中 Kubemetes 集 群 的 常见 部 署 方式 。 


第 14 章 ”资源 指标 及 HPA 探 制 需 


资源 监控 系统 是 容器 编排 系统 必 不 可 少 的 组 件 ， 它 为 用 户 提 供 了 
快速 了 解 系统 资源 分 配 和 利用 状态 的 有 效 途 径 ， 同 时 也 是 系统 编排 赖 
以 实现 的 基础 要 件 。 在 新 一 代 监控 架构 体系 中 ，Kubernetes 将 资源 指 
标的 规范 及 其 实现 分 离开 来 ， 为 用 户 提供 了 极 大 的 扩展 裤 间 。 本 章 将 
主要 说 明 如 何 为 Kubernetes 集 群 提供 资源 监控 机 制 并 利用 资源 指标 。 


14.1 质 源 监控 及 竺 源 指 标 


监控 应 用 程序 的 当前 状态 是 帮助 预测 问题 并 发 现 生产 环 境 中 资源 
瓶颈 的 最 有 效 方法 之 一 ， 但 它 也 十 目前 儿 乎 所 有 软件 开发 组 织 面 临 的 
最 大 挑战 之 一 ， 然 而 ， 微 服务 的 日 益 普 及 使 得 日 志 记 录 和 监控 变 得 更 
加 复杂 ， 因 为 大 量 正在 通信 的 应 用 程序 本 质 上 是 分 布 式 和 多 样 化 的 ， 
某 个 单 点 故障 甚至 可 以 中 断 整 个 系统 ， 但 识别 它 却 变 得 越 来 越 困 难 。 


当然 ， 监 控 只 是 微服 务 体系 中 众多 挑战 中 的 一 个 ， 此 外 ， 处 理 可 
用 性 、 性 能 和 应 用 部 署 等 必然 地 推动 了 团队 创建 或 使 用 编排 工具 来 处 
理 所 有 服务 和 主机 ， 这 也 是 Kubernetes 这 一 类 的 编排 系统 迅速 流行 的 
原因 之 一 ， 因 为 它 能 够 处 理 多 台 计 算 机 中 的 容器 ， 并 消除 了 处 理 分 布 
式 处 理 的 复杂 性 。 但 这 么 一 来 问题 又 转 为 了 如 何 有 效 地 监控 
Kubernetes 系 统 并 输出 指标 数据 。 


众所周知 ， 基 于 诸如 CPU 和 内 存 使 用 等 指标 自动 缩放 工作 负载 规 
模 的 能 力 是 Kubernetes 最 强大 的 功能 之 一 。 当 然 ， 要 启用 此 功能 ， 首 
完 需 要 一 种 收集 和 存储 这 些 指 标的 方法 ， 曾 经 ， 这 必然 是 指 
Heapster。 不 过 ， 传 统 的 基于 Heapster 收 集 的 数据 指标 进行 工作 负载 缩 
放 的 方法 仅 文 持 CPU 一 项 指标 ， 要 扩展 为 文 持 多 种 指标 可 能 有 着 不 小 
的 麻烦 ， 并 且 来 和 目 于 项 目的 各 种 贡献 者 的 文 持 也 不 一 致 ， 因 此 它 不 久 
后 可 能 会 被 淘汰 。 圣 运 的 是 ，Kubernetes 新 的 指标 API 实 现 了 一 种 更 为 
一 致 和 高 效 的 供给 指标 数据 的 方式 ， 这 为 以 目 定 义 指 标 为 基础 的 自动 
缩放 目标 提供 了 可 行 的 实现 。 


14.1.1 资源 监控 及 Heapster 


Kubernetes 有 多 个 数据 指标 需要 采集 相关 的 数据 ， 而 这 些 指标 大 体 
上 可 以 分 为 两 个 主要 组 成 部 分 : 监控 集群 本 身 和 监控 Pod 对 象 。 在 集群 
监控 层面 ， 目 标 是 监控 整个 Kubernetes 集 群 的 健康 状况 ， 包 括 集群 中 的 
所 有 工作 和 点 是 否 运行 正 帝 、 系 统 唤 源 容 量 大 小 、 每 个 工作 节点 上 运 
行 的 容 右 化 应 用 的 数量 以 及 整个 集群 的 资源 利用 率 等 ， 它 们 通 第 可 分 
为 如 下 一 些 可 衡量 的 指标 。 


1) 下 点 资源 状态 : 这 个 领域 的 众多 指标 都 与 资产 利 用 状况 有 关 ， 
主要 有 网 络 带宽 、 和 磁盘 空间 、CPU 和 内 存 的 利用 率 ; 基于 这 些 度 量 指 
标 ， 告 理 员 能 够 评估 集群 规模 的 合理 性 。 


2) 下 点 数量 : 当今 ， 从 多 公有 云 服务 两 均 以 客户 使 用 实例 数量 计 
算 费 用 ， 于 是 即时 了 解 到 集群 中 的 可 用 世 点 数量 可 以 为 用 户 计算 所 需 
要 文 付 的 费用 提供 参考 指标 。 


3) 运行 的 Pod 对 象 : 正在 运行 的 Pod 对 象 数 量 能 够 用 于 评估 可 用 节 
”0 以 及 在 节操 发 生 故 障 时 它们 是 否 能 够 承接 整个 工 
负载 。 


太一 方面 ， Pod 资 源 对 象 的 监控 需求 大 体 上 可 以 分 为 三 类 : 
Kubernetes 指 标 、 容 姨 指 标 和 应 用 程序 指标 。 


1) Kubernetes 指 标 : 用 于 监视 特定 应 用 程序 相关 的 Pod 对 和 象 的 部 署 
过 程 、 当 前 副本 数量 、 期 望 的 副本 数量 、 部 署 过 程 进 展 状 态 、 健 康 状 
态 监 测 及 网 络 服务 器 的 可 用 性 等 ， 这 些 指标 数据 需要 经 由 Kubernetes 系 
统 接口 获取 。 


_2) 容器 指标 : 容 句 的 资源 需求 、 资 源 限 制 以 及 CPU、 内存 、 磁 盘 
空间 、 网 络 市 宽 等 资源 的 实际 占用 状况 等 。 


3) 应 用 程序 指标 : 应 用 程序 自身 内 建 的 指标 ， 通 常 与 其 所 处 理 的 
业务 规则 相关 ， 例 如 ， 关 系 型 数据 库 应 用 程序 可 能 会 内 建 用 于 又 露 索 
引 状 态 有 关 的 指标 ， 以 及 表 和 关系 的 统计 信息 等 。 


监控 集群 所 有 市 点 的 一 种 方法 是 通过 DaemonSet 控 制 器 在 各 节操 部 
署 一 个 用 于 监控 指标 数据 采集 功能 的 Pod 对 象 运行 监 控 代 理 程序 
(agent) ， 并 在 集群 上 部 车 一 个 收集 从 下 点 上 由 代理 程序 采集 的 监控 
数据 的 中 心 监控 系统 ， 统 一 进行 数据 的 采集 、 存 储 和 展示 。 这 种 部 团 
方式 给 了 管理 员 很 大 的 自主 空 zs 间 ， 但 也 必定 难以 形成 统一 之 势 。 


于 是 ，Kubernetes 系 统 特地 于 kubelet 程 序 中 集成 相关 的 工具 程序 
cAdvisor， 用 于 对 方太 上 的 资源 及 容 右 进行 实时 监控 及 指标 数据 采集 ， 
支持 的 相关 指标 包括 CPU、 内 存 使 用 情况 、 网 络 否 吐 量 及 文件 系统 使 
用 情况 等 ， 并 可 通过 TCP 的 4194 端 口 提供 一 个 Web UI a 
部 署 未 启用 此 功能 ) 。 需 要 快速 了 解 某 特定 节点 上 的 CAdvisor 运 行 是 
正常 ， 以 及 了 解 单 太 点 的 资源 利用 状态 时 ， 可 直接 访问 cAdvisor Web 
UI，URL 是 http://<Node_IP>:4194/ ， 其 默认 的 界面 如 图 14-1 所 示 。 


© 172.16.0.66:4194/containers/ 


i 
May 8, 2018, 9:36:37 PM 


Total 0.4881799013832222 ~ 


9:35:45 PM 9:36:00 PM 9:36:15 PM 9:36:30 PM 9:36:45 PM 9:37:00 PM 9:37:15 PM 


图 14-1 cAdvisor 图 形 面板 


cAdvisor 的 问题 同样 在 于 其 仅 能 收集 单个 和 点 及 其 相关 Pod 资 源 的 
相关 指标 数据 。 事 实 上 ， 将 各 工作 万 点 采集 的 指标 数据 予以 汇集 并 通 
过 一 个 统一 接口 同 外 暴露 不 仅 能 为 用 户 市 去 便捷 ， 而 且 也 是 Kubernetes 
系统 某 些 组 件 所 依赖 的 压 层 功能 ， 这 些 组 件 包括 kubectl top 命 令 、 


Horizontal Pod Autoscalers 〈 即 HPA) 资源 以 及 Dashboard 的 某 些 功能 


O 


~]$ kubect] top nodes 
Error from server (NotFound): the server could not find the requested resource 
(get services http:heapster:) 


Heapster 是 这 类 项 目的 一 个 著名 实现 ， 用 于 为 集群 提供 指标 API 及 
其 实现 ， 并 进行 系统 监控 ， 而 且 它 曾 与 ClusterDNS、Ingress 和 
Dashboard 一 起 并 称 为 Kubernetes 的 四 大 核心 附件 ， 其 组 件 结构 如 图 14-2 
所 示 。 


Master 


Storage Backend 


图 14-2 ”Heapster 系 统 数 据 流 问 


Heapster 是 集群 级 别 的 监视 和 事件 数据 聚合 工具 ， 它 原生 文 持 并 且 
适用 于 所 有 方式 构建 的 Kubernetes 集 群 系统 。Heapster 本 身 可 作为 集群 
中 的 一 个 Pod 对 象 运行 ， 它 通过 发 现 集 群 中 的 所 有 节点 实现 从 每 个 节点 
kubelet 内 建 的 cAdvisor 获 取 性 能 和 指标 数据 ， 并 通过 标签 将 Pod 对 象 及 
其 相关 的 监控 数据 进行 分 级 、 聚 合 后 推送 到 可 配置 的 后 端 存 储 系统 进 
行 存 储 和 可 视 化 。 


功能 完备 的 Heapster 监 控 系 统 流行 的 解决 方案 是 由 InfluxDB 作 为 存 
储 后 端 ，Grafana 为 可 视 化 接口 ， 而 Heapster 从 各 下 点 的 CAdvisor 采 集 数 
据 并 存储 于 InfluxDB 中 ， 由 Grafana 进 行 展 示 。 托 管 于 Kubernetes 集 群 中 
的 InfluxDB、Grafana 和 Heapster 运 行为 常规 的 Pod 资 源 对 象 ， 它 们 彼此 
之 间 通 过 环境 变量 及 服务 发 现 功能 目 动 协同 。 另 外 ， 它 还 文 持 其 他 多 
种 后 端 ， 如 OpenTSDB、Elasticsearch、Log、Monasca、Kafka、 


Riemann 和 Hawkular-Metrics 等 ， 可 按 需 灵活 组 合 出 多 种 不 同 的 监控 解 
决 方案 。 


然而 ，Heapster 文 持 的 每 个 存储 后 端的 代码 都 直接 驻 留 在 其 代码 仓 
库 中 成 为 核心 代码 库 的 一 部 分 ， 结 果 是 必然 会 被 烂 尾 的 驻 留 代码 所 拖 
累 ， 这 甚至 是 成 为 了 用 户 使 用 Heapster 最 常见 的 挫败 原因 。 更 重要 的 
是 ， 即 使 Heapster 没 有 将 Prometheus 作 为 数据 接收 器 ， 却 又 暴露 了 
Prometheus 格 式 的 指标 ， 这 通常 会 引起 不 小 的 混 消 和 缸 烦 。 


换 句 话说 ，Heapster 既 为 那些 依赖 于 指标 数据 的 系统 组 件 提 供 了 指 
标 API 〈 非 标准 格式 的 一 等 类 别 Kubernetes API) ， 同 时 又 提供 了 指标 
API 授 口 背 后 的 实现 方式 ， 即 收集 和 存储 指标 数据 以 啊 应 对 API 的 请 
求 。 这 种 以 耦合 度 较 高 的 方式 实现 核心 系统 组 件 依赖 到 的 功能 部 件 的 
做 法 对 系统 的 变迁 引入 了 不 少 的 不 确定 性 和 隐患 。 


另外 ，Heapster 假 设 数据 存储 是 一 个 原始 的 时 间 序 列 数据 库 ， 这 些 
数据 库 都 有 着 一 个 可 直接 写 入 路 径 。 这 使 得 它 与 Prometheus 系 统 基本 上 
不 相 兼 容 ， 因 为 Prometheus 工 作为 拉 取 式 模 型 。 然 而 ，Kubernetes 生 态 
系统 的 整体 组 件 几 乎 原生 文 持 Prometheus 系 统 ， 于 是 ，Heapster 的 这 兰 
分 功能 逐渐 被 其 所 取代 。 


为 了 避免 重 蹊 Heapster 的 履 略 ， 资 源 指标 API (resource metrics 
api) 和 自 定义 指标 API (custom metrics api) 被 有 意 地 创建 为 纯粹 的 
API 定 义 而 非 具 体 的 实现 ， 它 们 作为 聚合 的 API 安 闭 到 Kubernetes 集 群 
中 ， 从 而 允许 在 API 保 持 不 变 的 情况 下 切换 其 具体 的 实现 方案 ， 这 一 点 
极 大 地 降低 了 二 者 的 耦合 级 别 。 最 终 ，Heapster 用 于 提供 核心 指标 API 
的 功能 也 被 聚合 方式 的 指标 API 服 务 器 metrics-server 所 取代 。 


14.1.2” 狐 一 代 监 控 染 构 


Kubernetes 如 此 强大 的 原因 之 一 便 是 其 灵活 的 可 扩展 性 ， 其 中 表 
现 得 尤为 抢眼 的 是 ， 它 通过 API 聚 合 器 为 开发 人 员 提 供 了 轻松 扩展 API 
资源 的 能 力 ，Kubernetes 在 1.7 版 本 中 引入 的 自 定义 指标 API (custom 
metrics API) ， 以 及 在 1.8 版 本 中 引入 的 资源 指标 API (resource metrics 
API， 人 简称 为 指标 API) 都 属于 这 种 类 型 的 扩展 。 


资源 指标 API 主 要 供 核 心 系统 组 件 使 用 ， 如 调度 程序 、HPA 
和 “kubectl top” 命 令 等 ， 虽 然 是 以 扩展 方式 实现 API， 但 它 提供 的 是 
kubernetes 系 统 必 备 的 “核心 指标 ”， 因 此 不 适用 于 与 第 三 方 监控 系统 集 
成 ， 如 Prometheus 等 。 男 一 方面 ， 自 定义 指标 API 则 为 用 户 提供 了 目 行 
按 需 扩展 指标 的 接口 ， 它 允许 用 户 目 定义 指标 类 型 的 API Server 并 直接 
聚合 进 主 API Server 中 ， 因 此 具有 更 广泛 的 使 用 场景 。 人 简单 总 结 起 来 就 
是 ， 新 一 代 的 Kubernetes 监 控 系 统 架 构 主 要 由 核心 指标 流水 线 和 监控 
指标 流水 线 协 同 组 成 ， 具 体 如 下 。 


(1) 核心 指标 流水 线 


由 kubelet、 资 源 评 估 硕 、metrics-server 以 及 由 API Server 提 供 的 
API 群 组 (由 APIService 对 象 提 供 ) 组 成 ， 如 图 14-3 所 示 ， 它 们 可 用 于 
为 Kubernetes 系 统 提 供 核 心 指标 ， 从 而 能 够 了 解 并 操作 其 内 部 组 件 和 
核心 程序 。 和 截至 目前 ， 相 关 的 指标 主要 包括 CPU 款 计 使 用 、 内 存 即 时 
使 用 率 、Pod 的 资源 占用 率 及 容器 的 磁盘 占用 率 等 儿 个 。 所 用 到 的 度 
量 标准 核心 系统 组 件 包 括 调度 逻辑 (基于 指标 数据 的 调度 程序 和 应 用 
规模 的 水 平 缩 放 ) ， 以 及 部 分 UI 组 件 (如 kubectl top 命 令 和 
Dashboard) 等 。 


(2) 监控 指标 流水 线 


监控 指标 流水 线 用 于 从 系统 收集 各 种 指标 数据 并 提供 给 终端 用 
户 、 存 储 系统 以 及 HPA 控 制 絮 等 使 用 ， 它 收集 的 数据 指标 也 称 为 非 核 
心 指标 ， 但 它们 通常 也 包含 核心 指标 (未 必 是 Kubemetes 可 以 理解 的 
格式 ) 以 及 其 他 指标 。 自 定义 指标 API 人 允许 用 户 扩 展 任 意 数 量 的 特定 
于 应 用 程序 的 指标 ， 例 如 ， 其 指标 可 能 包括 队列 长 度 和 每 秒 入 口 请 求 
数 等 。Kubernetes 系 统 本 刁 不 会 提供 此 类 组 件 ， 也 不 会 对 这 些 指标 提 


供 相关 的 解释 ， 它 有 赖 于 用 户 按 需 选择 使 用 的 第 三 方 解 决 方案 。 上 自 定 
义 指标 API 系 统 组 件 如 图 14-4 所 示 。 
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图 14-3 ”资源 指标 API 系 统 组 件 
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图 14-4 上 自 定 义 指标 API 系 统 组 件 


一 个 能 同时 使 用 资源 指标 API 和 目 定 义 指标 API 的 组 件 是 第 二 版 的 
HorizontalPod-Autoscaler 控 制 器 (HPAv2) ， 它 实现 了 基于 观察 到 的 指 
标 目 动 缩放 Deployment 或 ReplicaSet 类 型 控制 絮 管 控 下 的 Pod 副 本 数 
量 。HPA 的 第 一 个 版 本 只 能 根据 观察 到 的 CPU 利用 率 进行 扩展 ， 尽 管 
在 某 些 情况 下 很 有 用 ， 但 CPU 并 不 总 是 最 适合 目 动 调整 应 用 程序 的 度 


量 指标 。 


从 根本 上 来 讲 ， 资 源 指标 API 和 自 定义 指标 API 都 仅 是 API 的 定义 
和 规范 ， 它 们 自身 都 并 非 具体 的 API 实 现 。 目 前 ， 资 源 指标 API 的 实现 
较 主流 是 的 metrics-server， 而 自 定义 指标 API 则 以 建构 在 监控 系统 
Prometheus 之 上 的 k8s-prometheus-adapter 最 广 为 接 受 。 事 实 上 ， 
Prometheus 也 是 CNCF 旗 下 的 项 目 之 一 ， 并 且 得 到 了 Kubernetes 系 统 上 
众多 组 件 的 原生 支持 。 


14.2 ”资源 指标 及 其 应 用 


如 前 所 述 ， 目 Kubermetes 1.8 版 本 起 ， 诸 如 容 属 的 CPU 和 内 存 资源 
占用 状况 一 类 的 资源 利用 率 指 标 可 由 客户 端 通过 指标 API 直 接 调用 ， 
这 些 客户 端 包 括 但 不 限于 终端 用 户 、kubectl top 命 令 和 HPA (v2) 等 。 
另外 ， 尽 管 通 过 指标 API 能 够 查询 某 节 点 或 Pod 的 当前 资源 占用 情况 ， 
但 API 本 喘 并 不 存储 任何 指标 数据 ， 因 此 ， 它 仅 提 供 资 源 占 用 率 的 实 
时 监测 数据 而 无 法 提供 过 去 指定 时 刻 的 指标 监测 记录 结 


14.2.1 部 署 metrics-server 


事实 上， 资源 指标 API 与 系统 的 其 他 API 并 无 特别 不 同 之 外 ， 它 通 
过 API Server 的 URL 路 径 /apis/metrics.k8s.io/ 进 行 存 了 到， 并 提供 同样 级 别 
的 安全 性 、 稳 定性 及 可 靠 性 保证 。 不 过 ， 只 有 在 Kubernetes 集 群 中 部 
署 Metrics Server (指标 服务 器 ) 应 用 之 后 ， 指 标 API 方 才 可 用 。 资 源 指 
标 API 染 构 人 简 图 如 图 14-5 所 示 。 


Metrics Server 是 集群 级 别 的 资源 利用 率 数 据 的 聚合 妖 
(aggregator) ， 它 的 创建 于 不 少 方面 都 受到 了 Heapster 的 启发 ， 且 于 
功能 和 特性 上 完全 可 被 视 作 一 个 仅 服 务 于 指标 数据 的 简化 版 的 
Heapster。Metrics Server 通 过 Kubernetes 聚 合 堪 (kube-aggregator) 注 
册 到 主 API Server 之 上 ， 而 后 基于 kubelet 的 Summary API 收 集 每 个 节点 
上 的 指标 数据 ， 并 将 它们 存储 于 内 存 中 然后 以 指标 API 格 式 提供 ， 如 
14-6 所 示 。 
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图 14-5 “资源 指标 API 架 构 简 
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图 14-6 “聚合 metrics-server 于 主 API Server 上 


Metrics Server 基 于 内 存 存 储 ， 重 局 后 数据 将 全 部 丢失 ， 而 且 它 仅 
能 留存 最 近 收 集 到 的 指标 数据 ， 因 此 ， 如 果 用 户 期 望 访问 历史 数据 ， 
就 不 得 不 借助 于 第 三 方 的 监控 系统 (如 Prometheus 等 ) ， 或 者 自行 开 
发 以 实现 其 功能 。 


Metrics Server 是 Kubernetes 多 个 核心 组 件 的 基础 依赖 ， 因 此 ， 它 应 
该 默认 部 署 运行 于 集群 中 。 一 般 说 来 ，Metrics Server 在 每 个 集群 中 仅 
会 运行 一 个 实例 ， 启 动 时 ， 它 将 目 动 初始 化 与 各 市 点 的 连接 ， 因 此 出 
于 安全 方面 的 考虑 ， 它 需要 运行 于 普通 方 点 而 非 Master 主 机 之 上 。 直 
接 使 用 项 目 本 和 号 提供 的 资源 配置 清单 即 能 轻松 完成 metrics-server 的 部 
署 ， 下 面 就 来 分 步 说 明 其 实施 步骤 。 


(1) 克隆 项 目 代 码 的 仓库 至 本 地 目录 以 获得 其 资源 配置 清单 


~]$git clone https://github.com/kubernetes-incubator/metrics-server.git 


一 — 


注意 ， 截 至 目前 ，metrics-server 程 序 默认 会 从 kubelet 的 基于 HTTP 
通信 的 10255 端 口 获取 指标 数据 ， 但 出 于 安全 通信 的 目的 ，Kubernetes 
1.11 版 本 的 kubeadm 在 初始 化 集群 时 会 天 掉 kubelet 基 于 HTTP 的 10255 端 
口 ， 从 而 导致 其 部 署 完 成 后 无 法 正常 获取 数据 。 另 外 ， 代 码 仓库 中 的 
部 署 清单 文件 deplow1.8+/metrics-server-deployment.yaml 中 并 未 明确 为 
主 程序 /metrics-server 传 递 参 数 指 定 指标 数据 的 获取 接口 ， 它 通常 应 该 


是 kubernetes.summary_api。 因 此 ， 在 局 动 部 署 操 作 之 前 ， 需 要 修改 此 
清单 文件 ， 下 面 在 metrics-server 容 佛 配 置 段 中 添加 如 下 内 容 : 


command: 

- /metrics-server 

- --Source=kubernetes.summary_api:https://kubernetes.defaultkubeletHttps=true 
&kubeletPort=10250&insecure=true 


Metrics Server 项 目 处 于 非常 活跃 的 维护 状态 ， 其 相应 的 代码 仓库 
或 许 在 读者 读 到 此 书 时 便 已 完成 了 修正 ， 因 此 建议 进行 metrics-server 
部 署 时 先 不 做 修改 ， 待 部署 后 观测 到 连接 kubelet 销 误 一 类 的 信息 时 再 
予以 手动 更 正 。 


(2) 基于 资源 配置 清单 完成 相应 资源 的 创建 


~]$ kubectl1 apply -f metrics-server/deploy/1.8+/ 


各 部 署 清单 会 于 kube-system 名 称 空间 中 创建 出 多 个 类 型 的 资源 对 
象 ， 包 括 RBAC 相 关 的 rolebinding 、clusterrole 和 clusterrolebinding 对 
象 ， 以 及 serviceaccount 对 象 用 于 在 启用 了 RBAC 授 权 插 件 的 集群 上 完 
成 对 metrics-server 开 放 资 源 访问 的 许可 。 另 外 ， 它 还 会 通过 一 个 
APIService 对 象 创建 Metrics API 相 关 的 群 组 从 而 将 metrics-server 提 供 的 
API 聚 合 进 主 API Server 上 。 因 此 ， 接 下 来 要 检验 相应 的 API 群 组 
metrics.k8s.io 是 否 出 现在 Kubernetes 集 群 的 API 群 组 列表 中 : 


~]$ kubectl1 api-versions | grep metrics 
metrics.k8s.io/vibetal 


(3) 确认 相关 的 Pod 对 象 运行 正常 


首先 检查 metrics-server 的 Pod 对 象 是 否 处 于 “Running” 状 态 : 


~]$ kubect1 get pods -n kube-system -1 k8s-app=metrics-server 
NAME READY STATUS RESTARTS AGE 
metrics-server-778ddc45b5-hvwdh 1/1 Running 0 7m 


而 后 检查 Pod 中 的 容器 其 日 志 信 息 中 是 否 出 现 错误 提示 : 


~]$ kubectl1 logs metrics-server-778ddc45b5-hvwdh -n kube-system 


(4) 检查 资源 指标 API 的 可 用 性 


“kubectl get--raw” 命 令 可 用 于 基于 资源 URL 路 径 测 试 资源 指标 API 
服务 的 可 用 状态 ， 例 如 以 下 命令 应 返回 集群 中 所 有 市 点 的 资源 使 用 情 
况 指 标 列表 ， 它 能 够 列 出 集群 中 所 有 方 点 的 CPU 及 内 存 资 源 占 用 情 
0 也 可 以 直接 给 定 具 体 的 厄 点 标识 ， 从 而 仅 列 出 特定 市 


~]$ kubectl1 get --raw "/apis/metrics.k8s.io/vibetai/nodes" | jq. 


"kind": "NodeMetricsList", 
"apiVersion": "metrics.k8s.io/vibetal1", 
"metadata": 

"selfLink": "/apis/metrics.k8s.io/vibetai/nodes" 
}, 


(> 注意 “jq 是 专用 于 处 理 JSON 数 据 的 命令 行 工具 ， 其 功能 类 
似 于 sed 对 文本 信息 的 处 理 ， 在 CentOS 系 统 上 由 jg 程序 包 所 提供 。 


此 外 ，Pod 对 和 象 的 资源 消耗 信息 也 可 以 经 由 资源 指标 API 直 接 列 
出 ， 例 如 ， 要 获取 集群 上 所 有 Pod 对 象 的 相关 资源 消耗 数据 ， 可 使 用 
如 下 格式 的 命令 : 


~]$ kubect1l get --raw "/apis/metrics,k8s,1Io/v1lbetal/pods"” | jq 


资源 指标 API 支 持 HPA v2 控制 絮 根 据 资源 指标 (如 CPU 和 内 存 使 
用 量 ) 进行 扩展 ， 但 不 支持 使 用 特定 于 应 用 程序 的 指标 ， 那 些 特定 于 
应 用 程序 的 指标 需要 依赖 于 目 定 义 指 标 API。 执 行 完 成 上 述 步 骤 并 确 
认 结 果 无 误 后 ，metrics-server 即 成 功 部 署 完成 ， 那 些 依赖 于 核心 资源 
指标 的 控制 器 、 调 度 器 及 UI 工具 也 将 在 功能 上 得 到 进一步 的 完善 。 


14.2.2 ”kubectl top 命 令 


kubectl top 命 令 可 显示 节点 和 Pod 对 象 的 资源 使 用 信息 ， 它 依赖 于 
集群 中 的 资源 指标 API 来 收集 各 项 指标 数据 。 它 包含 有 node 和 pod 两 个 
子 命令 ， 可 分 别 用 于 显示 Node 对 象 和 Pod 对 象 的 相关 资源 占用 率 。 


列 出 Node 资 源 占 用 率 命 令 的 语法 格式 为 “kubectl top node[-l 
labellINAME]”， 例 如 下 面 显 示 所 有 节点 的 资源 占用 状况 的 结果 中 显示 
了 各 节点 标 计 CPU 资源 占用 时 长 及 百分比 ， 以 及 内 容 空间 占用 量 及 占 
用 比例 。 必 要 时 ， 也 可 以 在 命令 中 直接 给 出 要 查看 的 特定 节点 的 标 
识 ， 以 及 使 用 标签 选择 器 进行 节点 过 滤 : 


~]$ kubectl1 top node 


NAME CPU(cores) CPU% MEMORY(bytes) MEMORY% 
master .ilinux.io 444m 11% 1127Mi 65% 
node01.ilinux.io 158m 3% 558MI 32% 


而 名 称 空间 级 别 的 Pod 对 象 资源 占用 率 的 使 用 方式 会 略 有 不 同 ， 
使 用 时 ， 一 般 应 该 限定 名 称 空间 及 使 用 标签 选择 融 过 滤 出 目标 Pod 对 
象 。 命 令 的 语法 格式 为 “kubectl top podINAME|-1label][--all- 
namespaces][--containers=falseltrue]”， 例 如 ， 下 面 显 示 kube-system 名 称 
辣 中 标签 为 “k8s-app=kube-dns” 的 所 有 Pod 资 源 及 其 容器 的 资源 占用 


~]$ kubectl1 top pod -1 k8s-app=kube-dns --containers=true -n kube-system 


POD NAME CPU(cores) MEMORY (bytes) 
coredns-78fcdf6894-ncxdj coredns 3m 18Mi 
coredns-78fcdf6894-pvv88 coredns 3m 17Mi 


kubectl top 命 令 为 用 户 提供 了 简洁 、 人 快速 获取 Node 对 象 及 Pod 对 象 
占用 系统 资源 状况 的 接口 ， 是 集群 运行 和 维护 的 常用 命令 之 一 。 


14.3” 自 定义 指标 与 Prometheus 


除了 资源 指标 之 外 ， 用 户 或 管理 员 需 要 了 解 的 指标 数据 还 有 很 
多 ， 如 Kubernetes 指 标 、 更 全 面 的 容器 指标 、 更 全面 的 节点 资源 指标 及 
应 用 程序 指标 ， 等 等 。 目 定义 指标 API 人 允许 请 求 任意 指标 ， 其 指标 APIT 
的 实现 要 特定 于 相应 的 后 端 监视 系统 。Prometheus 是 第 一 个 开发 了 相应 
适配器 的 监控 系统 ， 毕 竟 它 是 监控 Kubernetes 的 第 一 选择 。 这 个 适用 于 
Prometheus 的 Kubernetes Custom Metrics Adapter 由 托管 在 GitHub 上 的 
k8s-prometheus-adapter 项 目 提供 ， 如 图 14-7 所 示 。 
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图 14-7 自 定义 指标 


目 定义 指标 API 时 目的 是 提供 最 终 用 户 和 Kubernetes 系 统 组件 可 以 
依赖 的 稳定 的 、 版 本 化 的 API， 但 其 可 用 的 实现 及 可 用 指标 则 有 赖 于 第 
三 方 或 用 户 的 自行 实现 ， 目 前 基于 Prometheus 收 集 和 存储 指标 数据 ， 并 
借助 于 k8s-prometheus-adapter 将 这 些 指 标 数 据 查 询 接 口 转换 为 标准 的 
Kubernetes 目 定义 指标 是 较为 流行 的 解决 方案 之 一 。 


14.3.1 Prometheus 概 述 


Prometheus 是 一 个 开源 的 服务 监控 系统 和 时 序数 据 库 ， 由 社交 音乐 
平台 SoundCloud 在 2012 年 开发 ， A CNC Nemes 收 条 的 第 寓 
二 款 产品 ， 目 前 已 经 成 为 Kubernetes 生 态 圈 中 的 核心 监控 系统 ， 而 且 越 
来 越 多 的 项 目 〈 如 etcd 等 ) 都 提供 了 对 Prometheus 的 原生 支持 ， 这 足以 
证 明 社 区 对 它 的 认可 程度 。 


Prometheus 提 供 了 通用 的 数据 模型 和 便捷 的 数据 采集 、 存 储 和 查询 
接口 。 其 核心 组 件 Prometheus 服 务 絮 定期 从 静态 配置 的 监控 目标 
(targets) 或 者 基于 服务 发 现 (service discovery) 自动 配置 的 目标 中 拉 
取 数 据 ， 产 拉 到 到 外 数据 大 于 配 晤 内 三 缓存 区 时 ， 数 据 将 持久 化 到 在 
1 包括 远程 云端 存储 系统 。Prometheus 的 生态 组 件 架构 如 图 
14-8 所 不 。 
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图 14-8 ”Prometheus 的 生态 组 件 架 构 


图 14-8 所 示 的 各 种 组 件 中 ， 每 个 被 监控 的 目标 (主机 、 应 用 程序 
等 ) 都 可 通过 专用 的 exporter 程 序 提供 输出 监控 数据 的 接口 ， 并 等 待 


Prometheus 服 务 顺 周期 性 的 数据 抓 取 操作 。 帮 存在 告警 规则 ， 则 抓 取 到 
数据 后 会 检查 并 根据 规则 进行 计算 ， 满 足 告警 条 件 即 会 生成 告警 ， 并 

发 送 到 Alertmanager 完 成 告警 的 汇总 和 分 发 等 操作 。 被 监控 目标 有 主动 
推送 数据 的 需求 时 ， 可 部 署 Pushgateway 组 件 接收 并 临时 存储 数据 ， 并 


等 待 Prometheus 服 务 器 完成 数据 采集 。 


任何 被 监控 的 目标 都 需要 事先 纳入 到 监控 系统 中 才能 进行 时 序数 
据 采 集 、 人 存储 、 告 警 及 相关 的 展示 等 ， 监 控 目 标 既 可 以 通过 配置 信息 
以 静态 形式 指定 ， 也 可 以 让 Prometheus 通 过 服务 发 现 机 制 动 态 管理 〈 增 
删 等 ) ， 对 于 变动 频繁 的 系统 环境 (如 容器 云 环 境 ) 来 说 ， 这 种 动态 
管理 机 制 尤为 有 用 。 在 Kubernetes 集 群 及 相关 的 环境 中 ， 除 了 此 前 配置 
的 从 Pod 对 象 中 的 容器 应 用 获得 资源 指标 数据 以 外 ，Prometheus 还 支持 
通过 多 个 监控 目标 采集 Kubernetes 监 控 架 构 体 系 中 所 谓 的 “ 非 核心 指标 
数据 *”， 如 图 14-9 所 示 。 
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图 14-9 ”Kubernetes 中 的 Prometheus 数 据 产 
1) 监控 代理 程序 ， 如 node_exporter， 


收集 标准 的 主机 指标 数据 ， 包 括 平 均 负 载 、CPU、Memory、 
Disk、Network 及 诸多 其 他 维度 的 数据 ， 独 立 的 指标 可 能 多 达 上 千 个 。 


2) kubelet (cAdvisor) : 收集 容器 指标 数据 ， 它 们 也 是 所 请 的 
Kubernetes“ 核 心 指 标 ?， 每 个 容器 的 相关 指标 数据 主要 有 CPU 利 用 率 
(user 和 和 system) 及 限额 、 文 件 系统 读 / 写 限额 、 内 存 利用 率 及 限额 、 网 
络 报 文 发 送 /接收 /丢弃 速率 等 。 


3) API Server: 收集 API Server 的 性 能 指标 数据 ， 包 括 控制 工作 队 
列 的 性 能 、 请 求 速率 与 延迟 时 长 、etcd 缓 存 工作 队列 及 缓存 性 能 、 羡 通 
人 (文件 描述 符 、 内 存 、CPU 等 ) 、Golang 状 态 (GC、 内 存 和 


4) etcd: 收集 etcd 存 储 集群 的 相关 指标 数据 ， 包 括 领导 节点 及 领域 
变动 速率 、 提 交 / 应 用 / 挂 起 /错误 的 提案 次 数 、 磁 盘 写 入 性 能 、 网 络 与 
gRPC 计 数 器 等 。 


5) kube-state-metrics: 此 组 件 能 够 派生 出 Kubernetes 相 关 的 多 个 指 
标 数 据 ， 主 要 是 资源 类 型 相关 的 计数 器 和 元 数据 信息 ， 包 括 指定 类 型 
的 对 象 总 数 、 资 源 限 额 、 容 器 状态 
(ready/restart/running/terminated/waiting) 以 及 Pod 资 源 的 标签 系列 等 。 


Prometheus 能 够 直接 把 Kubernetes API Server 作 为 服务 发 现 系统 使 
用 进而 动态 发 现 和 监控 集群 中 的 所 有 可 被 监控 的 对 象 。 这 里 需要 特别 
说 明 的 是 ，Pod 资 源 需 要 添加 下 列 注 解 信息 才能 被 Prometheus 系 统 上 自动 
发 现 并 抓 取 其 内 建 的 指标 数据 。 


1) prometheus.io/scrape: 用 于 标识 是 否 需 要 被 采集 指标 数据 ， 布 
尔 型 值 ，true 或 false。 


2) prometheus.io/path: 抓 取 指标 数据 时 使 用 的 URL 路 径 ， 一 般 


为 /metrics。 


3) prometheus.io/port 抓 取 指标 数据 时 使 用 的 套 接 字 端 口 ， 如 
8080。 


另外 ， 仅 期 望 Prometheus 为 后 端 生成 自 定义 指标 时 仅 部 署 
Prometheus 服 务 器 即 可 ， 它 甚至 也 不 需要 数据 持久 功能 。 但 若 要 配置 完 
整 功能 的 监控 系统 ， 管 理 员 还 需要 在 每 个 主机 上 部 署 node_exporter、 按 
需 部 署 其 他 特有 类 型 的 exporter 以 及 Alertmanager 。 


14.3.2 ”部 署 Prometheus 监 探 系统 


为 了 便于 用 户 快 速 集成 一 个 完整 的 Prometheus 监 控 环 境 ， 
Kubernetes 源 代码 的 集群 附件 目录 中 统一 提供 了 Prometheus 、 
Alertmanager、 node_exporter 和 kube-state-metrics 相 关 的 配置 清单 ， 路 径 
为 cluster/addons/prometheus， 每 个 项 目的 配置 清单 不 止 一 个 且 文 件 都 以 
项 目 名 称 开 起 。 将 Kubernetes 源 码 仓 库 克 隆 至 本 地 ， 以 便 在 后 面 的 各 配 
置 步 骤 中 应 用 其 配置 文件 : 


~]$git clone https://github.com/kubernetes/kubernetes.git 


为 了 便于 读者 理解 和 排除 问题 ， 下 面 分 步骤 分 别 说 明 kube-state- 
metrics、node_exporter、Alertmanager 和 Prometheus 四 个 组 件 的 部 署 过 


程 。 
1. 生 成 集群 唤 源 状态 指标 


kube-state- 人 API Server 上 收集 各 大 多 数 资源 
对 象 的 状态 信 ， 好 并 将 其 较为 指 绅 标 数据 ， 它 工作 于 HTTP 的 /metrics 接 口 ， 
通过 Prometheus 的 Go 语言 言 客 户 端 又 露 于 外 ，Prometheus 系 乡 充 以 及 任何 兼 
容 相关 客户 端 接口 的 数据 抓 取 工具 都 可 采集 相关 数据 ， 并 予以 存储 或 
展示 。 因 此 ， 再 结合 Prometheus 的 其 他 指标 数据 采集 接口 及 报警 功能 ， 
用 户 可 于 sa 义 建 出 一 个 上 自 定 义 指 标 API Server 的 同时 提供 一 个 
完整 的 监控 系统 


kube-state-metrics 是 Kubernetes 集 群 的 一 个 附加 组 件 ， 它 通过 
Kubernetes API service 监 听 资 源 对 象 的 状态 并 生成 相关 的 指标 ， 不 过 ， 
它 不 在 意 单个 Kubernetes 组 件 的 运行 状况 ， 而 是 关注 内 部 各 种 对 象 的 整 
体 运 行 状 况 ， 如 Deployment 对 象 或 ReplicaSet 对 象 等 。 换 句 话说 ，kube- 
state-metrics 的 重点 是 从 Kubernetes 的 对 象 状 态 生成 全 新 的 指标 。 


最 初 ，kube-state-metrics 是 作为 Heapster 的 另 一 个 指标 数据 源 而 开 
发 的 ，Heapster 只 需要 获取 、 格式 化 和 转 发 原 本 就 存在 的 指标 ， 特 别 是 
Kubernetes 组 件 的 指标 ， 并 将 它们 写 入 接收 妖 即 可 。 相 比 之 下 ，kube- 
state-metrics 在 内 存 中 保存 了 Kubernetes 系 统 状态 的 完整 快照 ， 并 不 断 生 


成 基于 它 的 新 指标 ， 但 不 负责 在 任何 地 方 导 出 指标 ， 那 是 Heapster 的 任 
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不 过 ， 有 些 监控 系统 (如 Prometheus) 根本 不 使 用 Heapster 进 行 指 
标 数据 收集 ， 而 是 目 我 实现 了 特有 的 收集 方式 ， 因 此 ， 将 kube-state- 
metrics 作 为 单独 的 项 目 ， 可 以 让 Prometheus 这 类 监视 系统 访问 也 能 使 用 
由 它 提 供 的 指标 。 目 前 ，kube-state-metrics 主 要 负责 为 CronJob、 
Deployment、PersistentVolumeClaim 等 各 类 型 的 资源 对 象 生 成 指标 数 
据 ， 各 类 资源 类 型 生成 的 指标 的 功能 及 用 法 请 参考 相关 的 文档 ， 地 址 
为 https://github.com/kubernetes/kube-state- 
metrics/tree/master/Documentation 。 


将 工作 目录 切换 到 元 隆 至 本 地 的 Kubernetes 项 目 源码 的 
cluster/addons/prometheus 目 录 中 ， 将 所 有 文件 名 以 kube-state-metrics 相 
天 的 配置 清单 创建 于 集群 中 即 能 完成 部 署 : 


~]$ cd kubernetes/cluster/addons/prometheus/ 
~]$ for file in kube-state-*; do kubectl apply -f $file; done 


部 署 完 成 后 会 于 kube-system 名 称 空间 创建 一 个 名 为 kube-state- 
metrics 的 Deployment 控 制 器 对 象 ， 其 所 生成 的 Pod 对 象 中 的 容器 应 用 将 
监听 于 8080 和 8081 端 口 以 提供 指标 数据 ， 除 此 之 外 ， 还 会 在 kube- 
system 名 称 空间 中 创建 一 个 同名 的 Service 对 象 为 客户 端 提供 固定 的 访问 
入 口 ， 用 户 也 可 以 通过 任何 类 型 的 HTTP 客 户 端 程序 测试 访问 其 原始 格 
式 的 指标 及 数据 。 例 如 ， 启 动 一 个 Pod 客 户 进 行 访问 测试 ， 命 令 如 下 : 


~]$ kubect1l run client-$RANDOM --image=cirros -it --rm -- sh 

/# curl -s kube-state-metrics.kube-system:8080/metrics | tail 

# HELP kube_service_ spec_type Type about service. 

# TYPE kube_service_ spec_type gauge 

kube_service_ spec_ type{namespace="default", service="kubernetes",type="ClusterIP"} 


分 别 通过 8080 和 8081 端 口 进行 确认 能 各 目 得 到 一 系列 的 指标 数 
据 ， 即 表示 kube-state-metrics 准 备 就 绪 。 


2.ExporterR Node Exporter 


Prometheus 通 过 HTTP 周 期 性 抓 取 指标 数据 ， 监 控 目 标 上 用 于 接收 
并 响应 数据 抓 取 请 求 的 组 件 统称 为 exporter。 目 前，Prometheus 项 目 及 
社区 提供 了 众多 现成 可 用 的 exporter， 分 别 用 于 监控 操作 系统 、 数 据 
库 、 硬 件 设备 、 消 息 队 列 、 存 储 系统 等 类 型 的 多 种 目标 对 象 。 


名 提示 “Prometheus 的 常用 exporter 列 表 位 于 


https://prometheus.io/docs/instrumenting/exporters/ 。 


在 监控 目标 系统 上 ，Exporter 将 收集 的 数据 转化 为 文本 格式 ， 并 通 
过 HTTP 对 外 炊 露 相应 的 接口 ， 它 不 会 局 限于 任何 编程 语言 或 实现 方 
式 ， 只 需要 它 能 够 接收 来 自 Prometheus 服 务 器 端的 数据 抓 取 请 求 ， 并 以 
特定 格式 的 数据 进行 啊 应 ， 因 此 它 尤 其 适用 于 容器 环境 。 


Exporter 的 啊 应 内 容 以 行为 单位 ， 其 中 ， 以 “#HELP” 开 头 的 是 注释 
信息 用 于 提供 指标 说 明 ， 以 “#TYPE” 开 头 的 注释 行 用 于 指明 当前 指标 
的 类 型 ， 它 可 以 是 counter、gauge、histogram 或 summary 其 中 之 一 ;， 空 
日 行将 被 忽略 。 


每 一 个 非 注 释 行 都 是 一 个 键 值 类 型 的 数据 ， 其 键 即 是 指标 ， 相 应 
的 值 是 当前 指标 本 次 啊 应 的 float 类 型 的 数据 ;者 返回 的 值 有 两 个 ， 则 最 
啊 应 值 必须 要 用 双 引 号 进行 引用 ， 人 否则 即 为 

式 错误 。 


Prometheus 为 监控 类 UNIX 操 作 系统 提 供 了 一 个 专用 的 
node_exporter 程 序 ， 它 能 够 收集 多 种 系统 级 指标 ， 如 conntrack、cpu、 
diskstats、meminfo、filesystem 、netstat 和 socketstats 等 数 十 种 。 
node_exporter 运 行为 守护 进程 监听 于 节点 上 的 9100 端 口 ， 通 过 URL 路 
径 /metrics 提 供 指标 数据 ，Prometheus 服 务 器 可 在 配置 文件 中 使 用 静态 
配置 监控 每 一 个 运行 node_exporter 的 目标 主机 ， 也 能 够 使 用 基于 文件 、 
Consul、DNS、Kubernetes 等 多 种 服务 发 现 机 制 动 态 添 加 监控 对 象 。 


事实 上 ， 监 控 Kubernetes 集 群 时 ， 每 个 节点 本 吴 束 能 通过 kubelet 或 
cAdvisor 提 供 符合 Prometheus 规 范 的 节点 指标 数据 ， 因 此 也 可 以 不 安装 
node_exporter 程 序 ， 甚 至 Kubernetes 为 部 署 Prometheus 服 务 器 提供 的 配 
置 清 单 中 也 没有 加 载 各 世 点 exporter 上 的 指标 。 不 过 ， 用 户 也 完全 可 以 
部 署 并 上 自行 配置 通过 node_exporter 进 程 节 点 进行 监控 。 


在 此 前 克隆 的 Kubernetes 源 码 目录 的 cluster/addons/prometheus 路 径 
下 执行 如 下 命令 便 可 完成 在 集群 中 各 斑点 上 部 署 并 运行 node_exporter， 
它 将 以 DaemonSet 控 制 器 对 象 于 各 节点 中 运行 一 个 相应 的 Pod 资 源 ; 


~]$ cd kubernetes/cluster/addons/prometheus/ 
~]$ for file in node-exporter-*; do kubectl] apply -f $file; done 


node_exporter 相 关 的 各 Pod 对 象 共享 使 用 其 所 在 市 点 的 网 络 名 称 空 
间 ， 它 直接 监听 于 相关 地 址 的 9100 端 点 ， 因 此 可 直接 对 其 中 某 一 个 
点 发 起 请 求 测试 : 


~]$ curl node01.ilinux.io:9100/metrics 


# HELP process virtual memory_bytes Virtual memory size in bytes. 
# TYPE process virtual memory_bytes gauge 
process_virtual memory_bytes 1.38784768e+08 


上 面 显 示 的 命令 响应 结果 中 ， 指 标 名 称 为 
process_virtual_memory_bytes， 相 应 值 为 float 格 式 ， 前 面 两 行 分 别 是 帮 
助 信息 及 指标 类 型 说 明 。 


3. 告 警 系 统 Alertmanager 


Prometheus 的 告警 功能 由 两 个 步骤 实现 ， 首 先是 Prometheus 服 务 丹 
根据 告警 规则 将 告警 信息 发 送 给 Alertmanager， 而 后 由 Alertmanager 对 
收 到 的 告警 信息 进行 处 理 ， 包 括 去 重 、 分 组 并 路 由 到 告警 接收 端 ， 文 
持 的 形式 包括 slack、email、pagerduty、hitchat 和 WebHook 等 接口 上 的 
联系 人 信息 。 


下 面 的 配置 文件 片断 取 目 kubemetes 源 码 目 杂 中 的 
cluster/addons/prometheus/alertmanager-configmap.yaml 文 件 ， 它 是 一 个 
ConfigMap 对 象 ， 用 于 为 运行 于 Pod 中 的 Alertmanager 提 供 配 置信 息 : 


global: null 
receivers.: 
- name: default-receiver 
route: 
group_interval: 5m 
group_wait: 10s 
receiver: default-receiver 
repeat_interval: 3h 


上 上面 的 配置 信息 非常 简洁 ， 全 局 配置 参数 (global) 为 空 ， 告 警 接 
收 端 (receivers) 只 有 一 个 default-receiver， 路 由 (route) 逻辑 


要 提供 的 配置 请 读者 参考 Alertmanager 的 相关 文档 。 


Prometheus 附 件 的 配置 清单 中 ，Alertmanager 的 Deployment 对 象 配 
置 容 希 使 用 了 持久 存储 卷 ， 它 定义 在 Pod 模 板 中 ， 存 储 卷 类 型 为 
persistentVolumeClaim ， 此 部 署 前 需要 确保 能 为 其 提供 使 用 的 存储 
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另外 ，Alertmnanager 的 守护 进程 通过 9093 端 口 提供 了 一 个 Web UL 
用 于 检查 和 过 滤 告 警 信息 。 如 需 于 Kubernetes 集 群 之 外 访问 此 接口 ， 这 
里 选择 将 其 Service 对 象 设 定 为 NodePort 类 型 ， 并 绑 定 固定 的 30093 端 
口 ， 配 置 片 断 如 下 所 示 : 


spec: 
ports: 
- name: http 
port: 80 
protocol: TCP 
targetPort: 9093 
nodePort: 30093 
selector: 
k8s-app: alertmanager 
type: "NodePort" 


en 


条 件 满足 后 ， 即 可 部 署 Alertmanager: 


~]$ cd kubernetes/cluster/addons/prometheus/ 
~]$ for file in node-exporter-*; do kubect1 apply -f $file; done 


部 署 完 成 后 打开 其 Web UI 即 可 过 滤 和 查看 告警 信息 ， 主 界面 如 图 
14-10 所 示 。 
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图 14-10 Alertmanager 的 Web UI 
4. 部 署 Prometheus 服 务 器 


Prometheus 服 务 器 是 整个 监控 系统 的 核心 ， 它 通过 各 exporter 周 期 
性 采集 指标 数据 ， 存 储 于 本 地 的 TSDB (Time Series Database) 后 端 存 
储 系统 中 ， 并 通过 PromQL 向 客户 端 提供 查询 接口 。 


由 Kubernetes 项 目 提供 的 附件 配置 清单 中 ，Prometheus 使 用 
StatefulSet 配 置 对 象 ， 各 Pod 对 象 通过 volumeClaimTemplates 对 象 申 请 使 
用 持久 存储 卷 ， 因 此 部 署 前 需要 确保 能 为 其 提供 使 用 的 存储 卷 。 另 
外 ，Prometheus 也 提供 了 Web UI， 通 过 9090 端 口 输出 ， 测 试 使 用 时 ， 可 
以 配置 其 通过 NodePort 类 型 的 Service 对 象 进 行 输出 : 


~]$ cd kubernetes/cluster/addons/prometheus/ 
~]$ for file in prometheus-*; do kubectl apply -f $file; done 


确认 各 相关 资源 对 象 得 以 正确 创建 ， 且 相关 的 Pod 都 能 正常 运行 无 
误 后 即 完成 部 署 。 此 时 ， 于 Prometheus 的 Web GUI 的 Targets 状 态 页 面 中 
可 看 到 相关 市 点 的 发 现 结果 ， 如 图 14-11 所 示 。 
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图 14-11 ”Prometheus 的 监控 目标 


PromQI (Prometheus Query Language) 是 Prometheus 专 有 的 数据 查 
询 语 言 (DSL) ， 其 提供 了 简洁 且 贴 近 自 然 语言 的 语法 实现 了 时 序数 
据 的 分 析 计 算 能 力 。PromQL 表 现 力 丰富 ， 支 持 条 件 查 询 、 操 作 符 ， 并 
旦 内 建 了 大 量 内 置 贸 数 ， 可 供 客户 端 针对 监控 数据 的 各 种 维度 进行 查 
询 。PromQL 的 使 用 方式 请 参考 相关 的 文档 或 书籍 。 


14.3.3” 目 定义 指标 适 配 疾 k8s-prometheus-adapter 


Prometheus 提 供 的 PromQL 接 口 无 法 直接 作为 自 定 义 指标 数据 源 ， 
它 并 非 Kubernetes 系 统 的 聚合 API 服 务 右 ， 它 们 之 间 还 需要 一 个 中 间 
层 “Kubernetes Custom Metrics Adapter for Prometheus”， 目 前 最 流行 的 
目 定 义 指 标 适 配 右 是 托管 于 Github 之 上 的 k8s-prometheus-adapter 项 目 。 


目 定义 的 Kubernetes API Server 必 须要 基于 HTTPS 与 客户 端 进行 通 
信 ， 因 此 为 了 便于 部 署 ， 这 些 程序 大 多 数 会 生成 一 个 目 签 证 书 。 不 
过 ，k8s-prometheus-adapter 项 目 提 供 的 配置 清单 要 使 用 一 个 名 为 cm- 
adapter-serving-certs 的 Secret 对 象 加 载 由 用 户 目 行 提供 的 证 书 。 于 是 ， 
部 署 之 前 需要 以 合理 的 方式 生成 证 书 并 配置 为 Secret 对 象 。 这 里 选择 以 
Master 主 机 系统 管理 员 的 号 份 基于 Kubernetes 的 CA 为 其 等 署 一 个 目 制 
证 书 : 


~]# cd /etc/kubernetes/pki/ 
~]# (umask 077; openss] genrsa -out serving.key 2048) 
~]# openssl req -new -key serving.key -out serving.csr -Subj "/CN=serving" 
~]# openssl x509 -req -in serving.csr -CA /etc/kubernetes/pki/ca.crt \ 
-CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out serving.crt -days 3650 


k8s-prometheus-adapter 默 认 会 部 署 在 custom-metrics 名 称 空 间 ， 
此 需要 将 相关 证 书 和 私 钥 作 为 此 名 称 空间 中 的 Secret 对 象 。 


O 注意 ”证书 和 私 钥 两 个 数据 项 的 相应 键 名 必须 为 serving.crt 
和 serving.key ° 


~]$ kubectl1 create namespace custom-metrics 
~]$ kubectl1 create secret generic cm-adapter-serving-certs -n custom-metrics \ 
--from-file=serving.crt=./serving.crt --from-file=serving.key=./serving.key 


确认 创建 完成 后 即 可 部 署 k8s-prometheus-adapter， 部 署 清单 位 于 
0 条 中 。 克 隆 到 相关 的 代码 并 将 资源 创建 于 集群 
Dp : 


~]$ git clone https://github.com/DirectXMan12/k8s-prometheus-adapter .git 
~]$ kubectl apply -f k8s-prometheus-adapter/deploy/manifests/ 


资源 创建 过 程 中 会 在 kube-aggregator 上 注册 新 的 API 群 组 
custom.metrics.k8s.io， 待 相关 的 Pod 对 象 转 为 正常 运行 状态 之 后 即 可 通 
过 kubectl api-versions 命 令 确 认 其 API 接 口 注 册 的 结 


~]$ kubectl1 api-versions | grep custom 
custom,.metrics,.k8s.io/vibetali 


| 问 custom.metrics.k8s.io 群 组 直接 发 送 请 求 即 可 列 出 其 可 用 的 所 有 
目 定 义 指 标 ， 例 如 ， 这 里 使 用 “kubectl get--raw” 命 令 进 行 测试 ， 并 使 用 
jd 命令 过 小 结果 ， 仪 列 出 指标 名 称 : 


~]$ kubectl1 get --raw "/apis/custom.metrics.k8s.io/vibetai" | jq 
'.resources[].name' 

"pods/kube_pod_container_status_running" 

"pods/kube_pod_info" 


另外， 也 可 以 直接 通过 API 查 看 指定 的 Pod 对 象 的 相应 指标 及 其 
值 ， 例 如 ， 可 以 使 用 类 似 如 下 的 命令 列 出 kube-system 名 称 空 间 中 的 所 
有 Pod 对 象 的 文件 系统 占用 率 : 


~]$ kubectl1 get --raw \ 
"/apis/custom.metrics.k8s.io/vibetai/namespaces/kube-system/pods/*/memotry_usage_ 
bytes" | jq. 


上 面 的 命令 会 列 出 相应 名 称 空间 中 所 有 Pod 对 和 象 的 内 存 资源 占用 
状况 ， 一 个 数据 项 的 显示 结果 足以 了 解 其 啊 应 格式 ， 例 如 下 面 的 内 容 
截取 自命 令 结果 中 关于 coredns 的 Pod 对 象 的 相关 输出 : 


"describedobject": { 
"kind": "Pod", 
"namespace": "kube-system", 
"name": "coredns-78fcdf6894-cft19"， 
"apiVersion": "/__internal" 


F 
"metricName": "memory_usage_bytes", 
"timestamp": "2018-08-28T04:54:322Z", 


"Value": "40189952" 
} 


CC 


14.4 目 动弹 性 缩放 


Deployment、ReplicaSet、Replication Controller 或 StatefulSet 控 制 
堪 资 源 管 探 的 Pod 副 本 数量 文 持 手 动 方式 的 运行 时 调整 ， 从 而 更 好 地 
匹配 业务 规模 的 实际 需求 。 不 过 ， 手 动 调整 的 方式 依赖 于 用 户 深度 参 
与 监控 容器 应 用 的 资源 压力 并 且 需 要 计算 出 合理 的 值 进 行 调整 ， 存 在 
一 定 程度 的 滞后 性 。 为 此 ，Kubernetes 提 供 了 多 种 自动 弹性 伸缩 
(Auto Scaling) 工具 ， 具 体 如 下 。 


RC/Deployment 


图 14-12” ”HPA 控制 器 示意 图 


.HPA: 全 称 Horizontal Pod Autoscaler， 一 种 支持 控制 器 对 象 下 Pod 
规模 弹性 伸缩 的 工具 ， 目 前 有 两 个 版 本 的 实现 ， 分 别称 为 HPA 和 HPA 
(v2) ， 前 一 种 仅 文 持 把 CPU 指标 数据 作为 评估 基准 ， 而 新 版 本 支持 
可 从 资源 指标 API 和 自 定义 指标 API 中 获取 的 指标 数据 。HPA 控 制 器 示 
意图 如 图 14-12 所 示 。 


.CA: 全 称 Cluster Autoscaler， 是 集群 规模 目 动 弹性 伸缩 工具 ， 能 
自动 增 减 GCP、AWS 或 Azure 


.集群 上 部 署 的 Kubernetes 集 群 的 节点 数量 ，GA 版 本 目 Kubernetes 
1.8 起 可 用 。 


:VPA: 全 称 Vertical Pod Autoscaler, 是 Pod 应 用 垂直 伸缩 工具 ， 它 
通过 调整 Pod 对 象 的 CPU 和 内 存 资 源 需 求 量 完成 扩展 或 收缩 ， 目 前 仍 处 
于 alpha 阶 段 。 


.AR: 全 称 Addon Resizer， 是 一 个 简化 版 本 的 Pod 必 用 垂直 伸缩 工 
具 ， 它 基于 集群 中 的 节点 数量 来 调整 附加 组 件 的 资源 需求 量 ， 当 前 仍 
处 于 beta 级 别 。 


14.4.1 HPA 概 壕 


尽管 Cluster Autoscaler 高 度 依赖 基础 云 计 算 环境 的 底层 功能 ， 但 
HPA、VPA 和 AR 可 以 独立 于 IaaS 或 PaaS 云 环境 运行 。HPA 可 作为 
Kubernetes API 资 源 和 控制 絮 实 现 ， 它 基于 采集 到 的 资源 指标 数据 来 调 
整 控 制 妖 的 行为 ， 控 制 器 会 定期 调整 ReplicaSets 或 Deployment 控 制 絮 
0 副本 数 ， 以 使 得 观察 到 的 平均 CPU 利用 率 与 用 户 指定 的 目标 


HPA 自 身 是 一 个 控制 循环 (control loop) 的 实现 ， 其 周期 由 
controller-manager 有 的 --horizontal-pod-autoscaler-sync-period 选 项 来 定 
义 ， 默 认为 30 秒 。 在 每 个 周期 内 ，controller-manager 将 根据 每 个 HPA 
定义 中 指定 的 指标 查询 相应 的 资源 利用 率 。controller-manager 从 资源 
指标 API 〈 针 对 每 个 Pod 资 源 指标 ) 或 自 定 义 指 标 API (针对 所 有 其 他 
指标 ) 中 获取 指标 数据 。 


.对 于 每 个 Pod 资 源 指标 (如 CPU) ， 控 制 器 都 将 从 HPA 定 位 到 的 

每 个 Pod 的 资源 指标 API 中 获取 指标 数据 。 若 设置 了 目标 利用 率 (target 
utilization) 标准 ， 则 HPA 控 制 器 会 计算 其 实际 利用 率 

(utilized/requests) 。 若 设置 的 是 目标 原始 值 ， 则 直接 使 用 原始 指标 
值 。 然 后 控制 器 获取 所 有 目标 Pod 对 象 的 利用 率 或 原始 值 的 均值 ( 取 
决 于 指定 的 目标 类 型 ) ， 并 生成 一 个 用 于 缩放 所 需 副 本 数 的 比率 。 不 
过 ， 对 于 未 定义 资源 需求 量 的 Pod 对 象 ，HPA 控 制 器 将 无 法 定义 该 容器 
的 CPU 利用 率 ， 并 且 不 会 为 该 指标 采取 任何 操作 。 


.对 于 每 个 pod 对 象 的 自 定义 指标 ，HPA 控 制 器 的 功能 与 每 个 pod 资 
源 指标 的 处 理 机 制 类 似 ， 只 是 它 仅 能 够 处 理 原始 值 而 非 利用 率 。 


不 过 ， 使 用 HPA 控 制 妖 管理 Pod 对 象 副本 规模 上 时， 由 于 所 评估 指标 
的 动态 变动 特性 ， 副 本 数量 可 能 会 频 索 波动 ， 这 种 现象 有 时 也 称 为 “ 持 
动 ”。 从 Kubernetes 1.6 版 本 开始 ， 集 群 管理 员 可 以 通过 调整 kube- 
controller-manager 的 选项 值 定义 其 变动 延迟 时 长 来 缓解 此 问题 。 目 
前 ， 默 认 的 缩 容 延迟 时 长 为 5 分 钟 ， 而 扩容 延迟 时 长 为 3 分 钟 。 


HPA 控 制 器 可 以 通过 两 种 不 同 的 方式 获取 指标 : Heapster 和 REST 
客户 端 接 口 。 使 用 直接 Heapster 获 取 指 标 数据 时 ，HPA 直 接 通 过 API 服 


务 辟 的 服务 代理 子 资 源 癌 Heapster 发 起 查询 请 求 ， 因 此 ，Heapster 需 要 
事先 部 署 在 群集 上 并 在 kube-system 名 称 空 间 中 运行 。 使 用 REST 客 户 端 
接口 获取 指标 时 ， 需 要 事先 部 署 好 资源 指标 API 及 其 API Server， 必 要 
时 ， 还 应 该 部 署 好 自 定义 指标 API 及 其 相关 的 API Server 。 


HPA 是 Kubernetes autoscalingAPI 群 组 中 的 API 资 源 ， 当 前 的 稳定 版 
本 仅 文 持 CPU 目 动 缩放 ， 它 位 于 autoscaling/v1 群 组 中 。 而 测试 版 本 包 
舍 对 内 存 和 目 定义 指标 的 扩展 文 持 ， 测 试 版 本 位 于 API 群 组 
autoscaling/v2betal 之 中 。 


另外 ， 目 Kubernetes 1.6 版 本 起 还 为 HPA 增 加 了 基于 多 个 指标 的 扩 
展 支持 ， 用 户 可 以 使 用 autoscaling/v2betalAPI 版 本 为 HPA 配 置 多 个 指标 
以 控制 规模 伸缩 。 运 行 时 ，HPA 控 制 絮 将 评估 每 个 指标 ， 并 基于 每 个 
指标 分 别 计算 出 各 目 控 制 下 的 新 的 Pod 规 模 数量 ， 结 果 值 最 大 的 即 为 
采用 的 新 规模 标准 。 


14.4.2 HPA (v1) 控制 器 


HPA 也 是 标准 的 Kubernetes API 资 源 ， 其 基于 资源 配置 清单 的 管理 
方式 同 其 他 资源 相同 。 男 外 ， 它 还 有 一 个 特别 的 “kubectl autoscale” 命 令 
用 于 快速 创建 HPA 控 制 器 。 例 如 ， 首 先 创 建 一 个 名 为 myapp 的 
Be i ， 而 后 通过 一 个 同名 的 HPA 控 制 器 自动 管控 其 Pod 副 

规模 : 


~]$ kubectl] run myapp --image=ikubernetes/myapp:v1i --replicas=2 \ 
--requests='cpu=50m, memory=256Mi' --limits='cpu=50m,memory=256Mi' \ 
--labels='app=myapp' --expose --port=80 

~]$ kubectl] autoscale deploy myapp --min=2 --max=5 --cpu-percent=60 


通过 命令 创建 的 HPA 对 象 隶属 于 “autoscaling/v1” 群 组 ， 因 此 ， 它 仅 
文 持 基于 CPU 利用 率 的 弹性 伸缩 机 制 ， 可 从 Heapster 或 Metrics Service 获 
得 相关 的 指标 数据 。 下 面 的 命令 用 于 显示 HPA 控 制 器 的 当前 状态 : 


~]$ kubect1l get hpa myapp -0 yaml 
apiVersion: autoscaling/vi 
kind: HorizontalPodAutoscaler 
metadata: 
spec: 
maxReplicas: 5 
minReplicas: 2 
scaleTargetRef: 
apiVersion: extensions/vibetal 
kind: Deployment 
name: myapp 
targetcCcPUUtilizationPpercentage: 60 
status: 
currentCcPUUtilizationpPercentage: 0 
currentReplicas: 2 
desiredReplicas: 2 


HPA 控 制 器 会 试图 让 Pod 对 象 相应 资源 的 占用 率 无 限 接 近 设 定 的 目 
标 值 。 例 如 ， 癌 myapp-svc 的 NodePort 发 起 持续 性 的 压力 测试 式 访问 请 
求 ， 各 Pod 对 和 象 的 CPU 利 用 率 将 持续 上 升 ， 直 到 超过 目标 利用 率 边 界 的 
60%， 而 后 触发 增加 Pod 对 和 象 副 本 数量 。 待 其 资源 占用 率 下 降 到 必须 要 
降低 Pod 对 象 的 数量 以 使 得 资源 占用 率 靠 近 目 标 设 定 值 时 ， 即 触发 Pod 
副本 的 终止 操作 ， 如 图 14-13 所 示 。 
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图 14-13 ”HPA 监控 指标 计算 


下 面 是 HPA 控 制 名 右 myapp 在 其 详细 信息 “Events” 中 的 一 段 内 容 ， 它 
显示 了 因 资 源 占用 率 过 高 而 增加 Pod 副 本 数量 ， 以 及 资源 占用 率 较 低 而 
降低 Pod 副 本 数量 的 部 分 探 作 事件 : 


Events: 
Type Reason Age” From Message 


Nama es 39m (x3 over 1h) horizontal-pod-autoscaler New 
size: 
5; reason: cpu resource utilization (percentage of request) above target 
Normal SuccessfulRescale 8m (x2 over 42m) horizontal-pod-autoscaler New 
size: 4; reason: All metrics below target 
Normal SuccessfulRescale 3m horizontal-pod-autoscaler New 
size: 2; reason: All metrics below target 


当然 ， 用 户 可 以 通过 资源 配置 清单 定义 HPA (v1) 控制 器 资源 ， 
其 spec 字 上 段 藤 套 使 用 的 属性 字段 主要 包 售 maxReplicas、minReplicas、 
scaleTargetRef 和 targetCPUUtilization- -Percentage 几 个 ， 其 使 用 方式 请 参 
考 相 应 的 文档 获取 。 尽 管 CPU 资 源 利 用 率 可 以 作为 规模 伸缩 的 评估 标 
Pod 对 象 所 面临 的 访问 压力 未 必 会 直接 反映 到 CPU 


14.4.3 HPA (v2) 控制 器 


HPA (v2) 控制 器 支持 基于 核心 指标 CPU 和 内 存 资源 以 及 基于 任 
意 目 定义 指标 资源 占用 状态 实现 应 用 规模 的 目 动弹 性 伸缩 ， 它 从 
metrics-server 中 请 求 查 看 核心 指标 ， 从 k8s-prometheus-adapter 一 类 的 目 
定义 API 中 获取 目 定 义 指 标 数据 ， 如 图 14-14 所 示 。 
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Aggregator 


core metrics 


metrics-server 


custom metrics 
| cAdvisor | 
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图 14-14 HPA (v2) 的 数据 指标 获取 方式 


下 面 是 一 个 HPA (v2) 控制 器 的 资源 配置 清单 示例 (hpa-v2- 
resources.yaml) ， 它 使 用 资源 指标 API 获 取 两 个 指标 CPU 和 内 存 资 源 
的 使 用 状况 ， 并 与 其 各 目的 设 定 目标 进行 比较 ， 计 算得 出 所 需要 的 副 
本 数量 ， 两 个 指标 计算 的 结果 中 数值 较 大 的 胜出 : 


apiVersion: autoscaling/v2betal 
kind: HorizontalPodAutoscaler 
metadata: 
name: myapp 
spec: 
scaleTargetRef: 
apiVersion: apps/v1 
kind: Deployment 
name: myapp 
minReplicas: 2 
maxReplicas: 10 
metrics: 
- type: Resource 
resource: 
name: cpu 
targetAverageUtilization: 50 
- type: Resource 
resource: 
name: memor 
targetAverageValue: 5OMi 


将 配置 清单 中 的 资源 创建 于 集群 中 即 可 进行 应 用 规模 伸缩 测试 ， 
其 测试 方式 与 14.4.2 节 中 的 过 程 相似 ， 这 里 不 再 给 出 其 具体 的 过 程 。 细 
心 的 读者 或 许 已 经 注意 到 ，HPA (v2) 尚且 处 于 beta 阶 段 将 来 它 有 
可 能 会 发 生 部 分 改变 , 但 目前 的 特性 足以 支撑 起 其 核心 功能 。HPA 

(v2) 控制 器 的 创建 语法 遵循 标准 的 API 资 源 格 式 ， 由 apiVersion、 
oy 、metadata 和 和 spec 字 上 段 组 成 ， 其 中 spec 字 上 段 主 要 骸 套 使 用 如 下 几 个 
字段 。 


minReplicas<integer>: 目 动 伸缩 可 缩减 至 的 Pod 副 本 数 下 限 。 


maxReplicas<integer>: 目 动 伸缩 可 扩展 至 的 Pod 副 本 数 上 限 ， 其 
值 不 能 低 于 min-Replicas 属 性 值 。 


scaleTargetRef<object>: 要 缩放 的 目标 资源 ， 以 及 应 该 收集 指标 
数据 并 更 改 其 副本 数量 的 Pod 对 象 ， 引 用 目标 对 象 时 ， 主 要 会 用 到 三 
个 藤 套 属性 一 apiVersion、kind 和 和 name 。 


:metrics<[]object>: 用 于 计算 所 需 Pod 副 本 数量 的 指标 列表 ， 每 个 
指标 单独 计算 其 所 需 的 副本 数 ， 将 所 有 指标 计算 结果 中 的 最 大 值 作为 
最 终 采 用 的 副本 数量 。 计 算 时 ， 以 资源 占用 率 为 例 ， 所 有 现 有 Pod 对 
象 的 资源 占用 率 之 和 除 以 目标 占用 率 所 得 的 结果 即 为 目标 Pod 副 本 
数 ， 因 此 增加 Pod 副 本 数量 必然 地 会 降低 各 Pod 对 象 的 资源 占用 率 。 


metrics 字 段 值 是 对 象 列表 ， 它 由 要 引用 的 各 指标 的 数据 产 及 其 类 
型 构成 的 对 象 组 成 。 


-external: 用 于 引用 非 附 属于 任何 对 象 的 全 局 指标 ， 甚 至 可 以 基于 
集群 之 外 的 组 件 的 指标 数据 ， 如 消 恩 队列 的 长 度 等 。 


:object: 引用 描述 集群 中 某 单 一 对 象 的 特定 指标 ， 如 Ingress 对 和 象 
上 的 hits-per-second 等 。 定 义 时 ， 骸 套 使 用 metricName 、target 和 
targetValue 分 别 用 于 指定 引用 的 指标 名 称 、 目 标 对 象 及 指标 的 目标 值 。 


-pods: 引用 当前 被 弹性 伸缩 的 Pod 对 象 的 特定 指标 ， 如 
transactions-processed-per-second 等 ， 各 Pod 对 和 象 的 指标 数据 取 平 均值 后 
与 目标 值 进 行 比较 。 定 义 时 ， 崩 套 使 用 metricName 和 
targetAverageValue 分 别 指定 引用 的 指标 名 称 和 目标 平均 值 。 


resource: 引用 资源 指标 ， 即 当 前 被 弹性 人 申 缩 的 Pod 对 象 中 容 噩 的 
requests 和 limits 中 定义 的 指标 《CPU 或 内 存 资源 ) 。 定 义 时 ， 代 套 使 用 
name targetAverageUftilization 和 targetAverageValue 分 别 用 于 指定 资源 


的 名 称 、 目 标 平均 利用 率 和 目标 平均 值 。 
type: 表示 指标 源 的 类 型 ， 其 值 可 为 Objects、Pods 或 Resource。 


基于 自 定义 指标 API 中 的 指标 配置 HPA 对 象 时 ， 其 指标 的 来 源 途 径 
还 包括 pods、object 和 external 等 ， 这 其 中 又 以 Pod 或 引用 的 特定 object 
和 。 下面 通过 一 个 示例 来 说 明 其 用 法 ， 并 测试 其 扩 缩 容 


镜像 文件 ikubernetes/metrics-app 在 运行 时 会 局 动 一 个 简单 的 Web 服 
务 器 ， 它 通过 /metrics 路 径 输出 了 http_requests_total 和 
http_requests_per_second 两 个 指标 。 下 面 是 使 用 此 镜像 文件 创建 的 
Deployment 控 制 妖 资源 配置 清单 示例 (metrics-app.yaml) ， 它 与 此 前 
正常 使 用 的 Deployment 资 源 定 义 并 无 二 致 ， 除 了 特别 附加 的 注解 信 
息 ， 包 括 其 中 的 “prometheus.io/scrape: "true"”* 是 使 Pod 对 和 象 能 够 被 
Prometheus 及 集 相 关 指 标的 天 键 配 置 . 


apiVersion: apps/vi1 
kind: Deployment 
metadata: 

labels: 


app: metrics-app 
name: metrics-app 
spec: 
replicas: 2 
selector: 
matchLabels: 
app: metrics-app 
template: 
metadata: 
labels: 
app: metrics-app 
annotations: 
prometheus.io/scrape: "true" 
prometheus.io/port: "80" 
prometheus.io/path: "/metrics" 
spec: 
containers: 
- image: ikubernetes/metrics-app 
name: metrics-app 
ports: 
- name: web 
containerPort: 80 
apiVersion: v1 
kind: Service 


metadata: 
name: metrics-app 
lJabels: 
app: metrics-app 
spec: 
ports: 
- name: web 
port: 80 
targetPort: 80 
selector: 


app: metrics-app 


创建 资源 于 集群 中 ， 局 动 一 个 专用 的 测试 客户 端 Pod， 在 命令 行 
中 辐 创 建 出 的 Service 端 点 的 /metrics 发 起 访问 请 求 即 可 看 到 它 输出 的 


Prometheus 兼 容 格式 的 指标 及 数据 : 


~]$ kubectl1 run client -it --image=cirros --rm -- /bin/sh 


/# curl metrics-app/metrics 


# HELP http_requests total The amount of requests in total 


# TYPE http_requests_ total counter 
http_requests_total 660 


# HELP http_requests per_second The amount of requests per second the latest ten 


seconds 
# TYPE http_requests per_second gauge 
http_requests_per_second 0.5 
/ # 


命令 结果 中 返回 了 所 有 的 指标 及 其 数据 ， 每 个 指标 还 附带 了 通过 
注释 行 提供 的 帮助 (HELP) 信息 和 类 型 (TYPE) 说 明 。Prometheus 
通过 服务 发 现 机 制 发 现 新 创建 的 Pod 对 象 ， 根 据 注解 提供 的 配置 信息 
或 默认 配置 识别 各 个 指标 并 纳入 采集 对 象 ， 而 后 由 k8s-prometheus- 
adapter 将 这 些 指标 注册 到 Kubernetes 的 目 定 义 指 标 API 中 ， 提 供给 HPA 
(v2) 控制 器 和 Kubernetes 调 度 器 等 作为 调度 评估 参数 使 用 。 当 然 ， 
用 户 也 可 以 直接 向 目 定 义 指标 API 接 口 发 起 请 求 。 


下 面 的 资源 配置 清单 示例 (metrics-app-hpa.yaml) 用 于 自动 弹性 
伸缩 前 面 基于 metrics-app.yaml 创 建 的 metrics-app 相 关 的 Pod 对 和 象 副本 数 
量 ， 其 伸缩 标准 是 接 入 HTTP 请 求 报 文 的 速率 ， 具 体 的 数据 则 经 由 各 现 
有 相关 Pod 对 象 的 http_requests 指 标的 平均 数据 同 目标 速率 800m ( 即 0.8 
个 / 秒 ) 的 比较 来 进行 判定 : 


kind: HorizontalPodAutoscaler 
apiVersion: autoscaling/v2betal 
metadata: 
name: metrics-app-hpa 
spec: 
scaleTargetRef: 
apiVersion: apps/vi1 
kind: Deployment 
name: metrics-app 
# autoscale between 2 and 10 replicas 
minReplicas: 2 
maxReplicas: 10 
metrics: 
# USe a "Pods" metric, which takes the average of the 
# given metric across all pods controlled by the autoscaling target 
- type: Pods 
pods: 
# USe the metric that you used above: pods/http_requests 
metricName: http_requests 
# target 500 milli-requests per second, 
# which is 1 request every two seconds 
targetAverageValue: 800m 


创建 资源 于 集群 中 ， 而 后 启动 一 个 测试 客户 端 发 起 持续 性 测试 请 
求 ， 模 拟 压力 访问 以 便 其 指标 数据 能 够 满足 扩展 规模 之 需 : 


~]$ kubect1l run client -it --image=cirros --rm -- /bin/sh 
/ # while true; do curl http://metrics-app; let i++; Sleep 0.$RANDOM; done 


持续 测试 十 几 分 钟 ， 结 束 后 再 等 上 一 段 时 间 ， 竺 平均 请 求 速率 降 
下 来 之 后 即 可 通过 HPA 控 制 器 的 详细 信息 了 解 其 规模 变动 状况 ， 然 后 
将 会 得 到 类 似 如 下 规模 变动 的 相关 信息 : 


Events: 
Type “Reason Age From Message 


Normal SuccessfulRescale 18m horizontal-pod-autoscaler New size: 3; 
reason: 
pods metric http_requests above target 
Normal SuccessfulRescale 14m horizontal-pod-autoscaler New size: 5; 
reason: 
pods metric http_requests above target 
Normal SuccessfulRescale 11m horizontal-pod-autoscaler New size: 6; 


reason: 
pods metric http_requests above target 
Normal SuccessfulRescale 5m horizontal-pod-autoscaler New size: 5; 
reason: 
All metrics below target 
Normal SuccessfulRescale 25s horizontal-pod-autoscaler New size: 4; 
reason: 


All metrics below target 


借助 目 定 义 指 标 目 动弹 性 伸缩 应 用 规模 的 机 制 ， 赋 予 了 不 同 应 用 
程序 根据 核心 指标 控制 目 喘 规模 的 能 力 ， 这 是 Kubemetes 系 统 除 敏捷 
部 署 (Deployment 等 控制 器 ) 功能 之 外 又 一 极 具 特色 的 特性 ， 其 使 得 
应 用 运 维 人 人员 从 繁重 的 日 常 监控 和 运 维 工作 中 解脱 出 来 。 


14.5 “本草 小 结 


本 章 介 绍 过 第 一 代 指 标 API 及 其 实现 方案 Heapster 之 后 ， 重 点 介绍 
了 第 二 代 监 控 架 构 体 系 、 资 源 指标 API、 目 定义 指标 API 及 其 各 目的 解 
决 方案 ， 并 对 HPA 及 HPA (v2) 的 使 用 给 予 了 详细 说 明 。 


.指标 API 是 HPA 控 制 器 、Dashboard 和 调度 器 依赖 的 基础 组 件 ， 它 
们 分 别 在 指标 数据 的 基础 上 实现 了 应 用 规模 的 弹性 伸缩 、 指 标 数据 的 
展示 和 Pod 对 象 的 调度 。 


.Heapster 是 第 一 代 的 指标 API 实 现 方案 ， 也 是 Kubernetes 系 统 曾经 
必 不 可 少 的 核心 附加 组 件 之 一 。 

.新 一 代 监 控 系 统 将 指标 划分 为 核心 指标 和 目 定 义 指 标 ， 并 把 APIT 
的 定义 同 其 实现 分 离开 来 。 资 源 指标 API 的 标准 实现 是 Metrics Server， 
而 自 定 义 指标 API 的 流行 实现 是 Promethues 及 相应 的 适配器 ， 如 k8s- 
prometheus-adapter ° 


HPA 控制 右 第 一 代 仅 支持 CPU 指 标 数据 ， 而 第 二 代 的 HPA 可 基于 
各 种 核心 指标 和 目 定义 指标 实现 应 用 规模 的 目 动 变动 。 


第 15 昔 ”Helm 程 序 包 管 理 器 


业务 的 容器 化 及 微服 务 化 过 程 基 本 上 都 是 通过 将 单 体 大 应 用 分 解 
为 多 个 小 的 服务 并 进行 容 絮 化 编排 运行 来 实现 的 ， 这 种 构建 逻辑 分 解 
了 单 体 应 用 的 复杂 性 ， 让 每 个 微服 务 都 能 够 独立 进行 部 署 和 扩展 ， 实 
现 了 敏捷 开发 和 运 维 。 但 另 一 方面 ， 微 服务 化 拆 解 巨大 的 单 体 应 用 为 
巨 量 的 微服 务 程 序 ， 几 乎 必然 地 导致 了 应 用 管理 复杂 度 的 增加 ， 例 
如 ， 在 Kubernetes 系 统 之 上 ， 每 个 应 用 基本 上 都 有 着 不 止 一 个 资源 ， 
而 每 个 应 用 在 不 同 的 环境 (如 ga、test 和 prod 等 ) 中 存在 使 用 不 同 的 配 
置 参数 的 可 能 性 等 复杂 问题 。 斑 运 的 是 ， 容 器 生态 系统 现在 已 经 发 展 
到 了 简便 程度 ， 因 为 有 了 Helm 。 


15.1 Hem 基 础 


由 前 面 章节 中 的 应 用 部 署 过 程 可 知 ， 在 Kubernetes 系 统 上 部 署 容器 
化 应 用 时 需要 事先 手动 编写 资源 配置 清单 文件 以 定义 资源 对 象 ， 而 且 
其 每 一 次 的 配置 定义 基本 上 都 是 硬 编码 ， 基 本 上 无 法 实现 复 用 。 对 于 
较 大 规模 的 应 用 场景 ， 应 用 程序 的 配置 、 分 发 、 版 本 控制 、 查 找 、 回 
滚 甚至 是 查看 都 将 是 用 户 的 置 梦 。Helm 可 大 大 简化 应 用 管理 的 难度 。 


简单 来 说 ，Helm 歼 是 Kubernetes 的 应 用 程序 包 管 理 器 ， 类 似 于 
Linux 系 统 之 上 的 yum 或 apt-get 等 ， 可 用 于 实现 帮助 用 户 查找 、 分 享 及 
使 用 Kubernetes 应 用 程序 ， 目 前 的 版 本 由 CNCF (Microsoft、Google 、 
Bitnami 和 Helm 社 区 ) 维护 。 它 的 核心 打包 功能 组 件 称 为 chart， 可 以 帮 
助 用 户 创建 、 安 装 及 升级 复杂 应 用 。 


Helm 将 Kubernetes 的 资源 (如 Deployments、Services 或 ConfigMap 
等 ) 打包 到 一 个 Charts 中 ， 制 作 并 测试 完成 的 各 个 Charts 将 保存 到 Charts 
仓库 进行 存储 和 分 发 。 另 外 ，Helm 实 现 了 可 配置 的 发 布 ， 它 支持 应 用 
配置 的 版 本 管理 ， 简 化 了 Kubernetes 部 署 应 用 的 版 本 控制 、 打 包 、 发 
布 、 删 除 和 更 新 等 操作 。Helm 架 构 组 件 如 图 15-1 所 示 。 


Kubernetes cluster 


Chart 
| repository 


| local System 


图 15-1 Helm 架 构 组 件 


简单 来 说 ， Helm 其 实 就 是 一 个 基于 Kubernetes 的 程序 包 (资源 包 ) 
管理 器 ， 它 将 一 个 应 用 的 相关 资源 组 织 成 为 Charts， 并 通过 Charts 管 理 
程序 包 ， 其 使 用 优势 可 简单 总 结 为 如 下 几 个 方面 : 


-管理 复杂 应 用 : Charts 能 够 描述 哪怕 是 最 复杂 的 程序 结构 ， 其 提供 
了 可 重复 使 用 的 应 用 安装 的 定义 。 


-易于 升级 : 使 用 就 地 升级 和 目 定 义 钩子 来 解决 更 新 的 难题 


-简单 分 享 : Charts 易 于 通过 公共 或 私有 服务 完成 版 本 化 、 分 享 及 主 
机 构建 。 


: 回 深 : 可 使 用 “helm rollback”* 命 令 轻 松 实现 快速 回 深 。 


15.1.1 Helm 的 核心 术语 


Helm 将 Kubernetes 应 用 的 相关 配置 组 织 为 Charts， 并 通过 它 完 成 应 
用 的 常规 管理 控 作 。 通 和 常 来 说 ， 使 用 Charts 管 理应 用 的 流程 包括 从 0 开 
始 创建 Charts、 将 Charts 及 其 相关 的 文件 打包 为 归档 格式 、 将 Charts 存 
储 于 仓库 (repository) 中 并 与 之 交互 、 在 Kubernetes 集 群 中 安装 或 和 扼 
载 Charts 以 及 管理 经 Helm 安 装 的 应 用 的 版 本 发 行 周期 。 因此， 对 Helm 
来 说 ， 它 具有 以 下 几 个 关键 概念 。 


:Charts， 即 一 个 Helm 程 序 包 ， 它 包含 了 运行 一 个 Kubernetes 应 用 
所 需要 的 镜像 、 依赖 关系 和 资源 定义 等 ， 必要 时 还 会 包含 Service 的 定 
义 ; 它 类 似 于 APT 的 dpkg 文 件 或 者 yum 的 rpm 文 件 。 


.Repository: Charts 仓 库 ， 用 于 集中 存储 和 分 发 Charts， 类 似 于 Perl 
的 CPAN， 或 者 Python 的 PyPI。 


-Config: 应 用 程序 实例 化 安 闻 运行 时 使 用 的 配置 信息 。 


.Release: 应 用 程序 实例 化 配置 后 运行 于 Kubernetes 集 群 中 的 一 个 
Charts 实 例 ; 在 同一 个 集群 上 ， 一 个 Charts 可 以 使 用 不 同 的 Config 重 复 
安装 多 次 ， 每 次 安装 都 会 创建 一 个 新 的 Release。 

事实 上 ，Charts 更 像 是 存储 于 Kubernetes 集 群 之 外 的 程序 ， 它 的 每 
次 安装 是 指 在 集群 中 使 用 专用 配置 运行 一 个 实例 ， 执 行 过 程 有 点 类 似 
于 在 操作 系统 上 基于 程序 启动 一 个 进程 。 


15.1.2 ”Helm 架构 


Helm 主 要 由 Helm 客 户 端 、Tiller 服 务 器 和 Charts 仓 库 (repository) 
组 成 ， 如 图 15-2 所 示 。 


Helm 客 户 端 是 命令 行 客户 端 工具 ， 采 用 Go 语言 编写 ， 基 于 gRPC 
协议 与 Tiller server 交 互 〈 见 图 15-2) 。 它 主要 完成 如 下 任务 。 


Kubernetes Cluster 
Kubernetes Apl Server 


TDR 


gRPC 


图 15-2” ”Helm 成 员 间 通信 
.本 地 Charts 开 发 。 
.管理 Charts 仓 库 。 


.与 Tiller 服 务 器 交互 : 发送 Charts 以 安装 、 查 询 Release 的 相关 信息 
以 及 升级 或 凶 载 已 有 的 Release 。 


Tiller server 是 托管 运行 于 Kubernetes 集 群 之 中 的 容器 化 服务 应 用 ， 
它 接 收 来 目 Helm 客 户 端的 请 求 ， 并 在 必要 时 与 Kubernetes API Server 进 


行 交 互 。 它 主要 完成 以 下 任务 。 
.监听 来 自 于 Helm 客 户 端的 请 求 。 
.合并 Charts 和 配置 以 构建 一 个 Release 。 


. 问 Kubernetes 集 群 安 装 Charts 并 对 相应 的 Release 进 行 跟踪 。 
.升级 和 和 仓 载 Charts。 


通常 ， 用 户 于 Helm 客 户 端 本 地 遵循 其 格式 编写 Charts 文 件 ， 而 后 
即 可 部 署 于 Kuber-netes 集 群 之 上 运行 为 一 个 特定 的 Release。 仅 在 有 分 
发 需求 时 ， 才 应 该 将 同一 应 用 的 Charts 文 件 打包 成 归档 压缩 格式 提交 
到 特定 的 Charts 人 仓库。 仓库 既 可 以 运行 为 公共 托管 平台 ， 也 可 以 是 用 
户 目 建 的 服务 妖 ， 仅 供 特定 的 组 织 或 个 人 使 用 。 


15.1.3 ”安装 Helm Client 


Helm 的 安装 方式 有 两 种 ， 预 编译 的 二 进 制程 序 和 源码 编译 安装 。 
这 里 先 介 绍 预 编译 的 二 进 制程 序 的 安装 方式 ， 源 码 编 译 安装 的 方式 将 
在 15.1.4 节 的 Tiller 编 译 安装 中 一 并 说 明 。 


Helm 的 每 个 发 行 版 都 提供 了 主流 操作 系统 的 专用 版 本 ， 主 要 包括 
Linux、Mac OS 和 Windows， 用 户 安 装 前 按 需 下 载 合用 的 平台 上 的 相关 
发 行 版 本 即 可 。Helm 项 目 托管 在 GitHub 之 上 ， 项 目地 址 为 
https://github.com/kubernetes/helm 。 


安装 之 前 首先 下 载 合 用 版 本 的 压缩 包 并 将 其 展开 ， 本 示例 中 使 用 
的 是 v2.9.1 的 版 本 。 执 行 具体 命令 时 ， 和 需要 礁 换 为 下 载 到 的 版 本 : 


~]$tar-zxvf helm-v2.9.1-linux-amd64.tgz 


而 后 ， 将 其 二 进 制程 序 文件 复制 或 移动 到 系统 PATH 环 境 变 量 指向 
J ， 如 /usr/local/bin/ 目 录 (管理 员 用 户 才 有 写 入 文件 至 此 
目 : ) 


~]$sudo mv linux-amd64/helm/usr/local/bin/ 


Helm 的 各 种 管理 功能 均 可 通过 其 子 命令 完成 ， 获 取 其 使 用 帮助 ， 
直接 使 用 “help” 子 命令 即 可 : 


~]$helm help 


需要 注意 的 是 ，Helm 的 运行 依赖 于 本 地 安装 并 配置 完成 的 kubectl 
方 能 与 运行 于 Kubemetes 集 群 之 上 的 Tiller 服 务 硕 进行 通信 ， 因 此 ， 运 
行 Helm 的 万 点 也 应 该 是 可 以 正常 使 用 kubectl 命 令 的 主机 ， 或 者 至 少 是 
有 着 可 用 kubeconfig 配 置 文件 的 主机 。Mac OS 或 Windows 系 统 上 的 安 
装 方式 请 参考 Helm 官 方 文档 。 


15.1.4 安装 Tiller server 


Tiller 是 Helm 的 服务 絮 端 ， 一 般 应 该 运行 于 Kubernetes 集 群 之 上 ， 
不 过 ， 出 于 研发 使 用 的 目的 ， 也 可 以 将 其 部 署 于 本 地 ， 且 需要 能 够 与 
远程 Kubernetes 集 群 正 常 通 信 ， 这 里 选择 将 其 托管 运行 于 集群 之 上 。 
另外 ， 对 于 了 RBAC 授 权 插 件 的 Kubernetes 集 群 来 说 ， 还 需要 事先 创建 
相关 的 ServiceAccount 才 能 进行 安装 。 


下 面 的 资源 配置 清单 示例 中 (tiller-rbac.yaml) 定义 了 一 个 名 为 
tler 的 ServiceAccount， 并 通过 ClusterRoleBinding 将 其 绑 定 至 集群 管理 
员 角 色 cluster-admin， 从 而 使 得 它 拥有 集群 级 别 所 有 的 最 高 权限 : 


apiVersion: v1 
kind: ServiceAccount 
metadata: 

name: tiller 

MAES PASe kube-system 


pe rbac.authorization.k8s.io/vibetal 
kind: ClusterRoleBinding 
metadata: 
name: tiller 
roleRef: 
apiGroup: rbac.authorization.k8s.io 
kind: ClusterRole 
name: cluster-admin 
subjects: 
- kind: ServiceAccount 
name: tiller 
namespace: kube-system 


Il 
ee 
二 


将 上 面 清单 的 内 容 保 存 于 文件 中 ， 如 tiller-rbac.yaml， 而 后 执 和 
令 以 完成 绑 定 : 


~]$ kubect1 apply -f tiller-rbac.yaml 
serviceaccount "tiller" created 
clusterrolebinding,.rbac.authorization.k8s.io "tiller" created 


而 后 侠骨 如 下 命令 进行 Tiller server 环 境 的 初始 化 ， 完 成 Tiller 


server 安 装 


~]$ helm init --service-account tiller 


> 注意 helm init 命 令 进行 初始 化 时 ，Kuberntes 集 群 会 到 
gcr.io/kubernetes-helm/ 上 获取 需要 的 镜像 ， 镜 像 标 签 同 Helm 的 版 本 
号 。 请 确保 Kubernetes 集 群 能 够 正确 访问 此 镜像 仓库 。 


若 有 必要 ， 可 以 基于 SSL/TLS 实 现 Helm 和 和 Tiller 之 间 的 通信 ， 这 就 
需要 在 部 署 Tiller 时 为 其 指定 专用 的 选项 --tiller-tls-verify， 并 为 后 续 的 
所 有 Helm 命 令 额外 附加 --ds 选 项 。 部 署 完 成 后 可 使 用 "kubectl get 
pods” 命 令 确 认 Tiller Pod 运 行 正常 ， 如 下 面 的 命令 所 示 : 


~]$ kubectl1 get pods -n kube-system -1 app=helm 
NAME READY STATUS RESTARTS AGE 
tiller-deploy-5c688d5f9b-gt65w 1/1 Running 0 4m 


安装 完成 后 ， 运 行 “helm version” 命 令 即 可 显示 客户 端 和 服务 端的 
版 本 号 ， 知 两 者 均 显 示 正 常 ， 则 表示 安装 成 功 。 到 此 为 止 ， 运 行 于 
Kubernetes 集 群 中 的 Tiller Server 已 经 配置 完成 ， 管 理 员 可 按 需 实现 后 
续 的 其 他 管理 工作 ， 人 例如， 搜索 可 用 的 Charts， 安 装 Charts 到 集群 中 


和 。 
于 


如 果 希 望 在 安装 时 自 定 义 一 些 参数 以 设 定 其 运行 机 制 ， 例 如 Tiller 
的 版 本 或 者 在 Kubernetes 集 群 上 的 目标 名 称 空 间 ， 则 可 以 以 类 似 如 下 
方式 使 用 命令 : 

--Canary-image: 安装 canary 分 文 ， 即 项 目 Master 的 分 文 。 

-tiller-image: 安装 指定 版 本 的 镜像 ， 默 认同 Helm 版 本 。 

.--kube-context: 安装 至 指定 的 Kubernetes 集 群 。 


--tiller-namespace: 安装 至 指定 的 名 称 空间 ， 默 认为 kube- 
System 。 


此 外 ，Tiller 将 数据 存储 于 ConfigMap 资 源 中 ， 因 此 御 载 后 重新 安 
痛 并 不 会 导致 数据 丢失 ， 必 要 时 ， 管 理 员 尽 可 放心 重新 安 逆 或 升级 。 
邯 载 Tiller 的 方法 浓 用 的 有 两 种 方式 。 


1) kubectl delete deployment tiller-deploy--namespace kube-system 


2) helm reset 


至 此 ，Helm 和 Tiller 的 安装 设 定 工作 已 经 完成 ， 接 下 来 便 可 党 试 使 
用 Helm 禹 来 的 诸多 便捷 之 处 。 


15.1.5 ”Helm 快 速 入 门 


Charts 是 Helm 的 程序 包 ， 它 们 存储 于 Charts 仓 库 中 。Kubernetes 官 
方 的 Charts 仓 库 保 存 了 一 系列 精心 制作 和 维护 的 Charts， 仓 库 的 默认 名 
称 为 “stable”。 安 装 Charts 到 Kubernetes 集 群 时 ，Helm 首 先 会 到 
Kubernetes 官 方 的 Charts 仓 库 中 获取 到 相关 的 Charts， 而 后 将 其 安装 # 
创建 为 Release 。 


名 提示 “Helm 的 官方 仓库 为 https:/kubernetes- 
charts.storage.googleapis.com ， 进 行 后 续 的 操作 之 前 请 确保 拥有 访问 此 
站 点 的 能 力 。 


“helo repo” 相 关 的 命令 可 用 于 管理 使 用 的 Charts 仓 库 ， 其 update 子 
ee 使 用 的 默认 仓库 的 元 数据 信息 ， 其 命令 及 执行 结果 如 下 
修 \: 


~]$ helm repo update 

Hang tight while we grab the latest from your chart repositories... 
...Skip local chart repository 

,. .Successfully got an update from the "stable" chart repository 
Update Complete. * Happy Helming! * 


“helm search>” 命 令 可 列 出 stable 仓 库 中 维护 的 所 有 Charts 的 列表 ， 如 
下 面 命令 结果 中 列 出 的 部 分 Charts: 


~]$ helm search 


NAME CHART VERSION APP VERSION DESCRIPTION 

stable/coredns 0.9.0 1.0.6 CoreDNS is a DNS server that 
chains plugins and... 

stable/docker-registry 1.4.0 2.6.2 A Helm chart for Docker Registry 

stable/etcd-operator 0.7.7 0.7.0 Core0S etcd-operator Helm chart 


for Kubernetes 


stable/gitlab-ce 0.2.1 GitLab Community Edition 

stable/grafana 1.9.0 5.1.2 The leading tool for querying 
and visualizing t... 

stable/jenkins 0.16.1 2.107 Open source continuous inte- 
gration server. It S,,， 

stable/kubernetes-dashboard 0.6.8 1.8.3 General-purpose web UI for Kub- 
ernetes clusters 

stable/mysql 0.5.0 5.7.14 Fast, reliable, scalable, and 


easy to useopen-... 


也 可 以 为 search 命 令 添加 一 个 过 滤器 ， 仪 列 出 符合 条 件 的 Charts， 
例如 下 面 的 命令 以 redis 为 过 滤 条 件 ， 仅 显示 与 redis 相 关 的 所 有 Charts: 


~]$ helm search redis 


NAME CHART VERSION APP VERSION DESCRIPTION 

stable/prometheus-redis-exporter 0.1.1 0.16.0 Prometheus exporter for Redis 
metrics 

stable/redis 3.3.0 4.0.9 Open source, advanced key- 


value store. It is of... 


“helm inspect” 命 令 能 够 打印 出 指定 的 Charts 的 详细 信息 : 


~]$ helm inspect stable/redis 
appVversion: 4.0.9 
description: Open source, advanced key-value store. It is often referred to as a 
data 
structure server since keys can contain strings, hashes, lists, sets and sorted 
Sets ， 


安装 指定 的 Charts 为 Kubernetes 集 群 的 Release， 可 使 用 “helm 
instal]”* 命 令 进 行 ， 例 如 若 ts 则 为 命令 行使 用 “-n” 选 
项 指定 Release 名 称 即 可 。 当 然 ， 也 可 以 先 执行 安装 测试 ， 例 如 : 


~]$ helm install stable/redis -n redis --dry-run 
NAME : redis 


右 无 错误 信息 返回 ， 则 移 除 --dry-run 选 项 即 可 进 命令 
会 返回 安装 过 程 的 执行 步骤 ， 以 及 最 后 的 注意 信息 ， 它 们 通 第 是 应 用 
的 使 用 帮助 ， 因 此 是 需要 特别 注意 的 内 容 : 


~]$ helm install stable/redis -n redis 
NAME : redis 

LAST DEPLOYED: Thu May 17 13:10:11 2018 
NAMESPACE: default 

STATUS: DEPLOYED 


RESOURCES: 

==> vi/Secret 

NAME TYPE DATA AGE 
redis Opaque 1 0S 


==> v1i/Service 


NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE 


redis-master ClusterIP 10.105.63.22 <none> 6379/TCP 0s 
redis-slave ClusterIP 10.105.114.60 <none> 6379/TCP 0s 
NOTES: 


** please be patient while the chart is being deployed ** 
Redis can be accessed via port 6379 on the following DNS names from within your 


cluster: 


redis-master.default.svc.cluster.local for read/write operations 
redis-slave.default.svc.cluster.]local for read-only operations 


多 数 应 用 的 Charts 都 可 以 接受 用 户 提供 的 配置 参数 进行 特定 的 场景 
化 部 署 ， 所 有 可 配置 参数 都 会 通过 Charts 模 板 提 供 ， 用 户 把 需要 提供 参 
和 配置 文件 中 并 通过 -{ 命 令 行 选项 加 
车 O 


若 要 列 出 已 经 安装 生成 的 Release， 则 需要 使 用 “helm list” 命 令 : 


~]$ helm list 
NAME REVISION UPDATED STATUS CHART NAMESPACE 
redis 1 Thu May 17 13:10:11 2018 DEPLOYED redis-3.3.0 default 


而 要 删除 Release， 则 使 用 “helm delete” 命 令 即 可 。 


~]$ helm delete redis 
release "redis" deleted 


升级 或 回 深 应 用 ， 要 分 别 使 用 “helm upgrade” 和 “helm rollback” 命 
令 ， 而 且 还 可 以 使 用 “helm history” 命 令 获取 指定 的 Release 变 更 的 历 
史 。 不 过 ， 若 默认 仓库 中 不 存在 所 需要 的 某 Charts， 而 对 用 户 来 说 该 
Charts 是 日 常 部 署 任 务 ， 则 用 户 可 以 自行 编写 Charts 并 分 享 。 事 实 上 ， 
helm install 命 令 支 持 基于 多 种 安装 源 进 行 应 用 部 署 ， 这 包括 Charts 仓 
库 、 本 地 的 Charts 压 缩 包 、 本 地 Charts 目 孙 ， 甚 至 是 指定 革 个 Charts 的 
URL 。 


15.2 Helm Charts 


Charts 是 Helm 使 用 的 Kubernetes 程 序 包 打包 格式 ， 一 个 Charts 就 是 
一 个 描述 一 组 Kubernetes 资 源 的 文件 的 集合 。 事 实 上 ， 一 个 单独 的 
Charts 既 能 用 于 部 署 徐 单 应 用 ， 例 如 一 个 memcached Pod， 也 能 部 署 复 
杂 的 应 用 ， 如 由 HTTP 服务 右 、DB 服 务 右 、Cache 服 务 器 和 应 用 程序 服 
务 需 等 共同 组 成 的 Web 应 用 栈 。 


从 物理 的 角度 来 描述 ，Charts 是 一 个 遵循 特定 规范 的 目录 结构 ， 
它 能 够 打包 成 为 一 个 可 用 于 部 署 的 版 本 化 归档 文件 。 


15.2.1 Charts 文 件 组 织 结构 


一 个 Charts 职 是 按 特定 格式 组 织 的 目录 结构 ， 目 孙 名 即 为 Charts 
名 ,日 录 名 称 本 身 不 包含 版 本 人 信息。 例如， 一 个 jenkins Charts 的 目录 
结构 应 该 如 下 所 示 : 


jenkins/ 
Chart.yaml 
LICENSE 
README ,md 
requirements.yaml 
values.yaml 
charts/ 
templates/ 
templates/NOTES. txt 


日 如 结构 中 除了 charts/ 和 templates/ 是 日 如 之 外 ， 其 他 的 都 是 文 
件 。 它 们 的 基本 功用 如 下 。 


-Chart.yaml: 当前 Charts 的 描述 信息 ，yaml 格 式 的 文件 。 


.LICENSE: 当前 Charts 的 许可 证 信息 ， 纯 文本 文件 ， 此 为 可 选 文 


-README.md: 易 读 格式 的 README 文 件 ， 可 选 。 
requirements.yaml: 当前 Charts 的 依赖 关系 描述 文件 ， 可 选 。 
-Values.yaml: 当前 Charts 用 到 的 默认 配置 值 。 

:charts/: 目录 ， 存 放 当 前 Charts 依 赖 到 的 所 有 Charts 文 件 。 


templates/: 目录， 存放 当前 Charts 用 到 的 模板 文件 ， 可 应 用 于 
Charts 生 成 有 效 的 Kuber-netes 清 单 文 件 。 


-templates/NOTES.txt: 纯 文 本 文件 ，Templates 人 简单 使 用 注解 。 


尽管 Charts 和 Templates 目 录 均 为 可 选 ， 但 至 少 应 该 存在 一 个 Charts 
依赖 文件 或 一 个 模板 文件 。 男 外 ，Helm 保 留 使 用 charts/ 和 templates/ 日 


孙 以 及 上 面 列 出 的 文件 名 称 ， 其 他 文件 都 将 被 忽略 。 


15.2.2 ”Chart.yaml 文 件 组 织 格式 


Chart.yaml 用 于 提供 Charts 相 关 的 各 种 元 数据 ， 如 名 称 、 版 本 、 关 
键 词 、 维 护 者 信息 、 使 用 的 模板 引擎 等 ， 它 是 一 个 Charts 必 备 的 核心 
文件 ， 主 要 包含 以 下 字段 。 

name: 当前 Charts 的 名 称 ， 必 选 字段 。 

Version: 遵循 语义 化 版 本 规范 第 2 版 的 版 本 号 ， 必 选 字 段 。 

description: 当前 项 目的 单 语句 描述 信息 ， 可 选 字段 。 

keywords: 当前 项 目的 关键 词 列表 ， 可 选 字 段 。 

home: 当前 项 目的 主页 URL， 可 选 字段 。 

sources: 当前 项 目 用 到 的 源码 的 来 源 URL 列 表 ， 可 选 字段 。 


:maintainers: 项 目 维护 者 信息 ， 主 要 人 藤 套 name、email 和 URE 几 个 
属性 组 成 ， 可 选 字段 。 


-engine: 模板 引擎 的 名 称 ， 默 认为 gotp1， 即 go 模板 。 

-icon: URL， 指 回 当 前 项 目的 图 标 ，SVG 或 PNG 格 式 的 图 片 ， 可 
选 字段 。 

.appVersion: 本 项 目 用 到 的 应 用 程序 的 版 本 号 ， 可 选 字段 ， 且 不 
必 为 语义 化 版 本 。 

.deprecated: 当前 Charts 是 否 已 废弃 ， 可 选 字段 ， 布 尔 型 值 。 


:tillerVersion: 当前 Charts 依 赖 的 Tiller 版 本 号 ， 可 以 是 语义 化 版 本 
号 的 范围 ， 如 “>2.4.0”， 可 选 字段 。 


例如 ， 下 面 的 示例 信息 是 rediss Charts 中 使 用 的 Chartyaml 的 内 
容 ， 用 户 上 自行 定义 Charts 编 写 相 天文 件 时 ， 要 采用 类 似 的 文件 格式 : 


appVersion: 4.0.9 

description: Open source, advanced key-value store. It is often referred 
to as a data structure server since keys can contain strings, hashes, 
lists, sets and sorted sets. 

engine: gotpl 

home: http://redis.io/ 

icon: https://bitnami.com/assets/stacks/redis/img/redis-stack-220x234.png 

keywords: 

- redis 

- keyvalue 

- database 

maintainers: 

- email: containers@bitnami.com 
name: bitnami-bot 

name: redis 

sources: 

- https://github.com/bitnami/bitnami-docker-redis 

version: 3.3.0 


15.2.3 ”Charts 中 的 依赖 关系 


Helm 中 的 一 个 Charts 可 能 会 依赖 不 止 一 个 其 他 的 Charts， 这 种 依赖 
关系 可 经 requirements.yaml 进 行动 态 链 接 ， 也 可 直接 存储 于 charts/ 目 隶 
中 进行 手动 管理 。 不 过 ， 尽 管 手 动 管理 依赖 关系 对 个 别管 理 场 景 也 有 
着 些许 优势 ， 但 使 用 动态 管理 的 方式 却 是 推荐 的 首选 方式 。 


1.requirements.yaml 文 件 


requirements.yaml 文 件 本 质 上 只 是 一 个 简单 的 依赖 天 系列 表 ， 它 具 
有 类 似 如 下 定义 中 的 格式 中 的 可 用 字段 : 


dependencies: 


version: 

repository: 

alias: 

tags: 

condition: 

import-values: 
- child: 

parent: 


上 述 示 例 中 的 字段 基本 可 以 见 名 知 义 ， 具 体 如 下 。 
name: 被 依赖 的 Charts 的 名 称 。 
Version: 被 依赖 的 Charts 的 版 本 。 


repository: 被 依赖 的 Charts 所 属 的 仓库 及 其 URL; 如 果 是 非 官方 
的 仓库 ， 则 需要 先 用 helm repo add 命 令 将 其 添加 进 本 地 可 用 仓库 。 


alias: 为 被 依赖 的 Charts 创 建 一 个 别名 ， 从 而 让 当前 Charts 可 以 将 
所 依赖 的 Charts 对 应 到 新 名 称 ， 即 别名 ; 可 选 字段 。 


tags: 默认 情况 下 所 有 的 Charts 都 会 被 装载 ， 知 给 定 了 tags， 则 仅 
疤 载 那些 匹配 到 的 Charts。 


:condition: 类 似 于 tags 字 段 ， 但 需要 通过 目 定义 的 条 件 来 指明 要 
装载 的 charts 。 


-import-values: 导入 子 Charts 中 的 的 值 ， 被 导入 的 值 需 要 在 子 
charts 中 导出 。 


如 下 所 示 的 示例 ， 是 Wordpress Charts 中 定义 的 动态 依赖 关系 : 


dependencies: 
- name: mariadb 
version: 2.1.1 
repository: https://kubernetes-charts.storage.googleapis.com/ 
condition: mariadb ,enabJed 
tags : 
- wordpress-database 


一 旦 依赖 天 系 文件 配置 完成 ， 即 可 使 用 “helm dependency 
update” 命 令 更 狐 依赖 关系， 并 上 自动 下 载 被 依赖 的 Charts 至 charts/ 目 隶 


[© 


2.Charts 目 录 


震 需 要 对 依赖 关系 进行 更 多 的 控制 ， 则 所 有 被 依赖 到 的 Charts 都 
能 以 手工 方式 直接 复制 到 Charts 目 永 中 。 一 个 被 依赖 到 的 Charts 既 可 以 
年 归档 格式 ， 也 可 以 是 展开 的 目 永 格式 ， 不 过 ， 其 名 称 不 能 以 下 划 线 
(_) 或 点 号 (.) 开头 ， 此 类 文件 会 被 Charts 装 载 器 目 动 忽略 。 


例如 ，Wordpress Charts 依 赖 天 系 在 其 Charts 目 录 中 的 反映 类 似 如 
下 所 示 : 


charts/ 

-一 mariadb 

FF 一 Chart.yaml 

FF 一 README .md 

FF 一 tempJlates 

FF 一 Configmap .yam] 
FF 一 deployment .yaml 
FF 一 _helpers.tpl 

FF 一 NOTES ,txXt 

FF 一 pvc.yaml 

Co secrets.yaml 
CC svc.yaml 

FF 一 test-runner .yamJ] 


— tests.yaml 
— values.yaml 


15.2.4 ”模板 和 值 


Helm Charts 模 板 (template) 遵循 Go 模板 语言 格式 ， 并 文 持 50 种 
以 上 的 来 目 Spring 库 的 模板 函数 附件 ， 以 及 为 数 不 少 的 其 他 专用 画 
数 。 所 有 的 模板 文件 都 存储 于 Templates 目 好 中 ， 在 当前 Charts 被 Helm 
引用 时 ， 此 目录 中 的 所 有 模板 文件 都 会 传递 给 模板 引擎 进行 处 理 。 

模板 文件 中 用 到 的 值 (value) 有 如 下 两 种 提供 方式 。 

.通过 Charts 的 values.yaml 文 件 提供 ， 通 常用 于 提供 默认 值 。 


:在 运行 “helm install” 命 令 时 传递 包含 所 需要 的 目 定义 值 的 YAML 
文件 ， 此 处 传递 的 值 会 履 兰 默认 值 。 


下 面 的 示例 是 Wordpress Charts 中 Deployment 模 板 文 件 的 部 分 内 


遇 


apiVersion: extensions/v1betal 
kind: Deployment 
metadata: 
name: {{ template "fullname" . }} 
labels: 
app: {{ template "fullname" ， 
chart: "{{ .Chart.Name }}-{{ .Chart.Version }}" 
release: "{{ .Release.Name }}" 
heritage: "{{ .Release.Service }}" 
spec: 
replicas: 1 
template: 
metadata: 
labels: 
app: {{ template "fullname" . }} 
spec: 
containers: 
- name: {{ template "fullname" . }} 
image: "{{ .Values.image }}" 
imagePullPolicy: {{ default "" .Values.imagePullPolicy | quote }} 


示例 中 模板 相关 的 代码 部 分 会 由 模板 引擎 运行 ， 并 生成 相应 的 结 
果 。 供 依赖 的 值 可 由 values.yaml 文 件 或 由 用 户 在 运行 helm install 命 令 时 
通过 选项 提供 ， 除 此 之 外 ，char 模 板 还 包含 一 些 固定 的 预定 义 值 ， 如 
Release.Name 、 Release.Time 、 Release.Time 、 Release.Service 、 


Release.ISUpgrade、Release.IsInstall、Release.Revision、Chart.Name、 
Chart.Version、Files 和 Capabilities 等 。 


而 在 values.yaml 一 类 的 文件 中 定义 值 (value) 时 ， 既 可 以 将 它们 
定义 为 全 局 作用 域 ， 也 可 以 定义 为 仅 供 Charts 目 隶 下 的 某 个 Charts 所 使 
用 。 一 般 来 说 ， 上 级 Charts 可 访问 下 级 Charts 中 的 值 ， 但 下 级 Charts 不 
能 访问 其 上 级 Charts 的 值 。 


如 下 面 示例 中 的 内 容 ， 其 中 title 属 于 全 局 作用 域 ， 
max_connections 和 password 则 仅 属 于 mysql Charts，Pport 仅 属于 apache 
Charts: 


title: "My WordPress Site" # Sent to the WordPress template 
mysql: 

max_connections: 100 # Sent to MySQL 

password: "secret" 


apache : 
port: 8080 # Passed to Apache 


Go 模板 语法 请 参考 godoc 站 点 中 的 内 容 ， 地 址 为 
https://godoc.org/text/template 。 


15.2.5 其 他 需要 说 明 的 话题 


定义 Charts 时 还 需要 用 到 许可 证 文件 (License) 、 自 述 文件 
(README.md) 以 及 说 明文 件 (NOTE. txt) ， 0 
用 户 提 供 重要 的 使 用 帮助 及 注意 事项 等 。 基 于 Charts 的 格式 规范 ， 用 
户 即 可 自 定 义 相关 应 用 程序 的 Charts， 并 将 其 通过 仓库 完成 分 享 。 


Charts 中 也 文 持 使 用 文件 来 措 述 安装 、 配 置 、 使 用 和 许可 证 信 
电 。 一 般 说 来 ，README 文 件 必 须 为 Markdown 格 式 ， 因 此 其 后 绥 名 
通常 是 “.md”， 它 一 般 应 该 包含 如 下 内 容 。 

:当前 Charts 提 供 的 应 用 或 服务 的 描述 信息 

运行 当前 Charts 需 要 满足 的 条 件 。 

:values.yaml 文 件 中 选项 及 默认 值 的 描述 。 

:其 他 任何 有 助 于 安装 或 配置 当前 Charts 的 有 用 信息 。 

另外 ，templatesNOTES.txt 文 件 中 的 内 容 将 会 在 Charts 安 装 完成 后 
予以 输出 ， 通 常用 于 向 用 户 提供 当前 Charts 相 天 的 使 用 或 初始 访问 方 


式 的 信息 。 男 外 ， 使 用 “helm status” 命 令 查看 某 Release 的 相关 状态 信息 
上 时， 此 文件 中 的 内 容 也 会 输出 。 


15.2.6” 目 定义 Charts 


一 个 典型 的 服务 类 容 巍 化 应 用 通常 会 由 Pod 控 制 器 (常用 的 为 
Deployment) 、Service、ConfigMap、Secret、Ingress 和 
PersistentVolumeClaim 等 资源 对 象 组 成 ， 其 中 前 两 者 基本 上 是 必 备 的 资 
源 ， 后 面 三 个 则 可 按 需 进行 定义 。Helm Charts 包 含 了 这 些 组 件 的 yaml 
格式 的 资源 配置 文件 模板 ， 它 们 能 够 通过 values.yaml 配 置 文件 获取 模 
Cn 甚至 文 持 用 户 在 部 署 操作 的 运行 时 进行 


1. 生 成 一 个 空 Charts 


创建 一 个 新 Charts 的 有 效 方式 是 使 用 "helm create” 命 令 ， 它 能 够 在 
狐 目录 中 创建 一 个 名 为 mychart 的 新 图 表 。 例 如 ， 下 面 的 命令 会 于 命令 
执行 的 当前 日 录 中 创建 一 个 名 为 mychart 的 子 日 录 作 为 Charts 存 储 路 
从 : 


~]$ helm create mychart 
Creating mychart 


此 命令 会 初始 化 出 一 个 空 的 Charts 目 录 结 构 ， 它 有 着 所 需要 的 各 
个 核心 文件 : 


~]$ tree mychart/ 

mychart/ 

| 一 charts 

FF 一 Chart.yaml 

CC templates 

| 一 deployment .yaml 
_helpers.tpl 

三 ingress.yaml 

| 一 NOTES.txt 

[一 service.yaml 

— values.yaml 


由 命令 生成 的 各 文件 还 有 着 各 目 应 该 具有 的 通用 组 织 结构 框架 ， 
例如 ，Chart.yaml 文 件 的 默认 内 容 如 下 : 


apiVersion: v1 

appVersion: "1.0" 

description: A Helm chart for Kubernetes 
name: mychart 

version: 0.1.0 


事实 上 ， 它 其 至 直接 在 values.yaml 将 要 使 用 的 镜像 文件 定义 中 为 
,i 六 可 直接 安装 容 姨 化 Nginx 应 用 的 Charts， 其 中 的 部 分 内 
容 如 未 : 


replicaCount: 1 


image: 
repository: nginx 
tag: stable 
pullPolicy: IfNotPresent 


service: 
type: ClusterIP 
port: 80 


因此 ， 用 户 仅 需要 在 各 文件 现 有 框 染 的 基础 上 按 需 进行 修改 即 可 
定义 出 所 需 的 Charts 来 。 


2. 修 改 Charts 以 部 署 目 定义 服务 


这 里 以 此 前 使 用 的 容器 应 用 “ikubernetes/myapp: V1” 为 示例 来 说 明 
如 何 定 义 一 个 Charts。 使 用 “helm create” 命 令 生 成 的 Charts 会 创建 一 个 
用 于 运行 、 由 默认 值 提 供 的 镜像 的 Deployment 对 象 ， 这 正音 味 着 铬 要 
部 署 不 同 的 应 用 仪 通过 修改 values.yaml 中 的 引用 镜像 文件 即 可 。 当 
然 ， 必 要 上 时， 用户 还 需要 额外 人 确认 是 否 需 要 默认 的 Ingress 对 象 的 定 
义 ， 以 及 需要 额外 用 到 存储 资源 。 


例如 ， 这 里 将 values.yaml 文 件 的 内 容 修改 为 如 下 所 示 : 


repository: ikubernetes/myapp 
tag: vi 
pullPolicy: IfNotPresent 


service: 
type: ClusterIP 
port: 80 


ingress: 
enabled: false 


annotations: {} 
# kubernetes.io/ingress.class: nginx 
# kubernetes.io/tls-acme: "true" 
path: / 
hosts: 
- chart-example.1local 
tls: [] 
# - secretName: chart-example-tls 
# hosts : 
# - chart-example.1local 


resources: 
limits: 
cpu: 500m 
memory: 512Mi 
requests: 
cpu: 500m 
memory: 512Mi 


nodeSelector: {} 
tolerations: [] 


affinity: {} 


而 后 通过 “helm lint* 命 令 人 确认 修改 后 的 Charts 是 否 遵 循 最 住 实践 旦 
模板 格式 民 好 : 


~]$ helm lint mychart 
==> Linting mychart 
[INFO] Chart.yaml: Icon is recommended 


1 chart(s) linted, no failures 


多 数 情况 下 , “helm lint* 命 令 报 告 的 错误 信息 ， 根 据 其 错误 提示 中 


的 行 号 信息 即 能 定位 出 错误 所 在 。 确 保 一 切 问题 都 得 以 解决 之 后 ， 即 


可 通过 “helm install” 命 令 调 试 运行 以 查看 由 Charts 定 义 的 容器 化 应 用 是 


人 否 能 够 正确 部 署 ; 


~]$ helm install --name myapp --dry-run --debug ./mychart --set service.type= 
NodePort 
[debug] Created tunnel using local port: '40255' 


[debug] SERVER: "127.0.0.1:40255" 
[debug] original chart version: "" 
[debug] CHART PATH: /home/ik8s/charts/mychart 


NAME : myapp 
REVISION: 1 
RELEASED: Tue Jun 5 16:14:45 2018 


CHART: mychart-0.1.0 
USER-SUPPLIED VALUES: 
service: 

type: NodePort 


确认 上 述 命 令 输 出 信息 无 误 后 ， 移 除 命 令 中 的 “--dry-run” 选 项 后 
行 命令 即 可 完成 应 用 的 部 时 


~]$ helm install --name myapp ./mychart --set service.type=NodePort 
NAME : myapp 

LAST DEPLOYED: Tue Jun 5 16:20:22 2018 

NAMESPACE: default 

STATUS: DEPLOYED 


RESOURCES: 

==> vi/Service 

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE 
myapp-mychart NodePort 10.108.65.88 <none> 80:30315/TCP 1s 
==> v1i/Deployment 

NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE 
myapp-mychart 1 1 1 0 Os 

==> v1i/Pod(related) 

NAME READY STATUS RESTARTS AGE 
myapp-mychart-67b9997c8b-nbsfk 0/1 ContainerCreating 0 Os 
NOTES: 


1. Get the application URL by running these commands : 
export NODE_ PORT=$(kubectl get --namespace default -o jsonpath="{.spec.ports 
[90] .nodePort}" services myapp-mychart) 
export NODE_ IP=$(kubectl] get nodes --namespace default -0 jsonpath="{.items[0]. 
status.addresses[0].address}") 
echo http://$NODE_IP: $NODE_ PORT 


而 后 ， 通 过 上 述 NOTES 中 的 命令 提示 运行 相关 的 命令 获取 访问 端 
所 后 即 可 通过 浏览 占 访 问 相 应 的 服务 : 


~]$ export NODE_PORT=$(kubectl get --namespace default -oO \ 
jsonpath="{.spec.ports[0].nodePort}" services myapp-mychart) 
~]$ export NODE_IP=$(kubectl] get nodes --namespace default -o \ 
jsonpath="{.items[0].status.addresses[0].address}") 

~]$ echo http://$NODE_IP:$NODE_ PORT 

http://172.16.0.70:30376 


而 后 通过 浏览 器 访问 测试 所 部 署 的 myapp 应 用 。 


3.Charts 仓 库 (Repository) 


至 此 ， 一 个 自 定义 的 Charts 即 于 本 地 设 定 完成 ， 不 过， 它 仪 能 
于 本 地 访问 。 当 然 ， 用 户 也 可 以 通过 “helm package” 命 令 将 其 打包 为 tar 
格式 后 分 享 给 团队 或 者 社区 : 


~]$ helm package ./mychart 
Successfully packaged chart and saved it to: /root/charts/mychart-0.1.0.tgz 


Helm 将 在 工作 目录 中 创建 一 个 mychart-0.1.0.tgz 包 ， 它 使 用 
Chart.yaml 文 件 中 定义 的 元 数据 的 名 称 和 版 本 。 通 过 将 程序 包 作为 参数 
传递 给 helm install， 用 户 可 以 基于 该 程序 包 而 不 是 本 地 目录 进行 安 
FE: 


~]$ helm install --name myapp2 mychart-0.1.0.tgz --set Service,type=NodePort 


为 了 使 软件 包 更 容易 分 享 ，Helm 内 置 了 从 HTTP 服 务 器 安装 软件 
包 的 支持 。 运 行 时 ，Helm 读 取 服 务 絮 上 托管 的 仓库 索引 ， 该 索引 摘 述 
了 有 哪些 Charts 程 序 包 可 用 以 及 它们 位 于 何 处 。 使 用 “helm serve” 命 令 
即 可 运行 本 地 仓库 来 输出 本 地 创建 的 Charts: 


~]$ helm serve 
Regenerating index. This may take a moment ， 
Now serving you on 127.0.0.1:8879 


此 命令 会 占据 当前 终端 ， 于 是 ， 另 局 一 个 终端 即 可 测试 访问 本 地 
仓库 服务 中 的 Charts: 


~]$ helm search local 
NAME CHART VERSION APP VERSION DESCRIPTION 
local/mychart 0.1.0 1.0 A Helm chart for Kubernetes 


尽管 Helm 能 够 管理 本 地 仓库 ， 但 创建 好 的 Charts 如 需 问 外 分 圣 ， 
就 需要 为 其 创建 用 于 共享 的 仓库 ， 并 将 计划 共 至 的 所 有 Charts 都 放置 
于 仓库 中 。 事 实 上 ，Charts 仓 库 服务 句 束 是 HTTP 服 务 器 ， 任 何 能 文 持 
YAML 文 件 及 tar 文 件 传 输 的 HTTP 服 务 絮 程序 都 可 以 作为 仓库 服务 器 使 
用 。 不 过 ， 一 般 来 说 ， 一 个 仓库 应 该 有 一 个 index.html 主 页 用 于 拉 述 当 
前 仓库 中 的 所 有 Charts 及 其 元 数据 信息 。 然 而 ， 到 目前 为 止 ，Helm 并 


不 文 持 将 Charts 上 传 至 仓库 中 ， 因 为 这 样 做 会 对 仓库 服务 器 程序 多 出 

很 多 额外 的 要 求 ， 并 且 也 会 增加 其 配置 的 复杂 度 。 这 就 意味 着 ， 上 传 
Charts 到 仓库 中 需要 借助 于 其 他 手段 来 进行 ， 如 FTP 或 SSH 协 议 等 ， 田 
外 ， 如 需 自 建 Charts 仓 库 ， 则 各 流行 的 web 服务 器 程序 基本 上 都 能 满足 
要 求 ， 如 Apache 或 Nginx 等 。 安 全 起 见 ， 通 过 互联 网 提供 服务 时 ， 建 

议 使 用 HTTPS 的 服务 絮 提 供 仓 库 服务 。 


而 在 Helm 客 户 端 ， 仓 库 的 管理 需要 使 用 “helm repo” 命 令 进行 ， 它 
可 以 添加 、 删 除 、 列 出 、 及 索引 仓库 。 例 如 ， 使 用 如 下 命令 添加 
incubator 仓 库 以 便 使 用 更 多 的 Charts: 


~]$ helm repo add incubator http://storage.googleapis.com/kubernetes-charts- 
Incubator 


"incubator" has been added to your repositories 


列 出 所 有 可 用 的 仓库 列表 ， 可 以 使 用 “helm repo list* 命 令 进 行 : 


~]$ helm repo list 

NAME URL 

stable https://kubernetes-charts.storage.googleapis.com 

local http://127.0.0.1:8879/charts 

incubator http://storage.googleapis.com/kubernetes-charts-incubator 


仓库 服务 器 上 的 可 用 Charts 及 其 版 本 等 经 常会 发 生 更 新 ， 必 要 
时 ， 可 使 用 “helm repo update” 命 令 获 取 最 新 的 仓库 元 数据 信息 : 


~]$ helm repo update 

Hang tight while we grab the latest from your chart repositories... 
,. .Skip local chart repository 

,. .Successfully got an update from the "stable" chart repository 

,. .Successfully got an update from the "incubator" chart repository 
Update Complete. *Happy Helming! * 


而 要 删除 指定 的 仓库 配置 ，“helm repo remove<REPO_NAME>” 即 
可 轻松 完成 。 


4. 配 置 依赖 天 系 


构建 存在 依赖 关系 的 Charts 时 ， 还 需要 为 其 定义 依赖 项 ， 例 如 ， 
前 面 创建 的 myapp 依 赖 于 数据 库 管理 系统 MySQL 时 ， 在 mychart 的 日 录 


中 创建 requirements.yaml 文 件 给 出 依赖 的 Charts 列 表 定 义 其 依赖 关系 即 
可 ， 文 件 内 容 类 似 如 下 所 示 : 


dependencies: 
- name: mysql 
version: 0.6.0 
repository: https://kubernetes-charts.storage.googleapis.com 


而 后 ， 需 要 运行 “helm dependency update” 命 令 为 Charts 更 狐 依赖 天 
系 。 更 新 过 程 中 ，Helm 会 目 动 生成 一 个 锁定 文件 requirements.lock， 以 
便 后 续 再 次 获取 依赖 关系 时 使 用 已 知 的 工作 版 本 。 运 行 下 面 的 命令 来 
引入 定义 的 MySQL 依 赖 项 时 ， 会 目 动 下 载 MySQL 相 关 失 Charts 程 序 包 
至 mychart/charts 子 目录 中 ， 如 下 面 的 命令 输出 结果 所 示 : 


~]$ helm dependency update ./mychart 

Hang tight while we grab the latest from your chart repositories... 

Saving 1 charts 

Downloading mysql from repo https://kubernetes-charts.storage.googleapis.com 
Deleting outdated charts 


此 时 ， 再 次 部 署 myapp Charts， 束 会 同时 部 署 依赖 到 的 mysql 
Charts。 男 外 ， 用 户 也 可 以 手动 将 所 依赖 到 的 程序 包 直 接 放 置 于 
mychart/charts 目 隶 中 来 定义 依赖 天 系 ， 此 时 不 必要 再 使 用 


requirements.yaml 文 件 。 


15.3 Helm 实 践 : 部 署 EFK 日 志 管 理 系 统 


应 用 程序 的 日 志 收 集 和 监控 通常 是 其 必要 的 外 围 功 能 ， 它 们 有 助 
于 记录 、 分 析 性 能 表现 及 排查 故障 等 ， 例 如 此 前 在 查看 Pod 对 象 的 日 
志 时 使 用 的 kubectl log 命 令 便 是 获取 容 絮 化 应 用 日 志 的 一 种 方式 。 然 
而 ， 对 于 分 布 式 部 署 的 应 用 来 说 ， 类 似 这 种 逐一 查看 各 实例 相关 日 志 
的 方式 存在 着 操作 烦琐 且 效 率 低下 等 诸多 问题 ， 再 加 上 需要 额外 获取 
操作 系统 级 别 的 多 个 日 志 源 中 的 日 志 信 息 ， 其 管理 成 本 势必 会 进一步 
上 升 。 解 决 此 类 需求 的 常见 方案 是 使 用 集中 式 日 志 存 储 和 管理 系统 ， 
它们 于 各 布点 部 署 日 志 采 集 代 理 程 序 从 日 志 源 采集 日 志 并 发 往 中 心 存 
储 管理 系统 ， 并 经 由 单个 面板 进行 数据 可 视 化 。 事 实 上， 对 于 任何 基 
础 设施 或 分 布 式 系统 ， 统 一 日 志 管 理 都 是 必 不 可 少 的 基础 组 件 。 同 样 
地 ，Kubermnetes 也 要 实现 在 整个 集群 级 别 收集 和 聚合 日 志 ， 以 便 用 户 
可 以 从 单个 仪表 板 监控 整个 集群 ， 其 常用 的 架构 形式 之 一 ， 如 图 15-3 
所 示 。 一 种 流行 的 开源 解决 方案 是 将 fluentd 作 为 节点 级 代理 程序 进行 
日 志 采 集 ， 并 将 之 聚合 存储 于 Elasticsearch 进 行 日 志 分 析 ， 以 及 通过 
Kibana 进 行 数据 可 视 化 。 这 种 组 合 通常 简称 为 EFK 。 
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图 15-3 ”基于 节点 日 志 采 集 代理 完成 日 志 收 集 


在 Kubernetes 上 部 署 fluentd 和 Kibana 的 方式 易于 实现 ，fluentd 由 
DaemonSet 控 制 名 贱 震 了 集 如 中 的 各 万 点 ， 而 Kibana 则 由 Deployment 探 
制 絮 部 署 并 确保 其 持 读 运 行 即 可 。 但 Elastic- Search 是 一 个 有 状态 的 应 
用 ， 需 要 使 用 StatéfulSet 控制 硕 创 建 并 管理 相关 的 Pod 对 象 ， 而 且 它 们 
还 分 别 需 要 专用 的 持久 存储 系统 存储 日 志 数 据 ， 因 此 ， 其 部 署 过 程 较 
之 前 两 者 要 略为 烦 开 ， 其 部 署 架 构 如 图 15-4 所 示 。 


Kubernetes cluster 


Elasticsearch cluster 


图 15-4 “Kubernetes 集 群 上 的 fluentd、Elastic- search 和 Kibana 


可 用 的 部 署 方式 除了 Kubernetes 项 目 在 其 Addons 目 录 中 提供 了 资 
源 配置 清单 用 于 部 署 EFK 之 外 ，Kubeapps (https://hub.kubeapps.com ) 
， 分 别提 供 了 相应 的 Charts 定 义 以 帮助 用 户 通过 Helm 轻 松 完 


15.3.1 ElasticSearch 集 群 


ElasticSearch 相 关 Charts 位 于 Kubeapps 的 incubator 仓 库 中 ， 它 使 用 
StatefulSet 和 Deployment 控 制 絮 实现 了 一 个 可 动态 伸缩 的 ElasticSearch 集 
群 ， 并 将 集群 的 角色 分 离 为 三 类 节点 ， 客户 端点 (上 载 市 点 ) 、 
master 帮 点 和 data 记 点 ， 各 目 负载 实现 集群 的 一 部 分 功能 ， 如 图 15-5 所 
示 。 每 个 master 节 点 和 data 节 点 分 别 需 要 用 到 各 上 自 的 存储 卷 以 持久 存储 
数据 ，incubator/elasticsearch 默 认定 义 它们 通过 PVC 依 赖 于 default 或 指定 
的 存储 类 动态 创建 PV 存储 卷 。 
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图 15-5 ”多 角色 ElasticSearch 和 集群 


客户 端 万 点 : 也 称 上 载 节 点 或 摄取 节点 ， 负 责 执 行 由 一 个 或 多 个 
摄取 处 理 需 组 成 的 预 处 理 流水 线 。 需 要 两 个 以 上 客户 端 实例 的 场景 
不 多 见 ， 因 此 其 副本 数 通 常 为 2。 


-master 条 点 ， 人 负责 轻 量 级 群集 范围 的 相关 操作 ， 如 创建 或 删除 索 
引 、 跟 踩 并 判定 集群 的 成 员 世 点， 以 及 决定 将 哪些 分 斤 分 配 到 哪些 季 
扩 等 ， 因 此 ， 一 个 健康 的 集群 必须 要 有 一 个 稳定 的 主 节 点 。master 六 点 


的 数量 取决 于 公式 “(客户 端 副本 数 /2) +1” 的 计算 结果 ， 但 至 少 应 该 为 
3 oO 


-数据 让 态 ， 人 负 贡 保存 包含 编 入 索引 的 文档 的 分 片 ， 并 人 处理 与 数据 
相关 的 操作 ， 例 如 数据 的 增删 改 查 (CRUD) 、 搜 索 和 素 合 等 ， 这 些 操 
作 通 第 是 /O、 内 存 和 CPU 密 集 型 的 任务 ， 其 所 需 的 节点 数量 取决 于 存 
储 及 计算 的 实际 需求 ， 因 此 ， 监 视 这 些 资源 并 在 过 载 时 添加 更 多 的 数 
据 广 点 非 党 重要 。 


incubator/elasticsearch 的 部 署 模 板 中 定义 了 众多 配置 参数 ， 随 着 
Charts 版 本 的 从 代 ， 各 参数 的 默认 值 也 可 能 会 有 变动 ， 当 前 的 0.4.9 版 本 
中 ， 使 用 的 镜像 来 目 仓库 “centerforopenscience/elasticsearch”， 镜 像 文件 
的 标签 为 “5.42， 各 master 世 点 的 PVC 存 储 卷 大 小 都 是 4Gi， 各 data 厅 点 
的 PVC 存 储 卷 大 小 均 为 30Gi，rbac 相 关 的 各 资源 创建 为 禁用 状态 。 部 署 
于 生产 环境 时 ， 默 认 设置 中 的 资源 请 求 和 资源 限制 ， 以 及 data 闻 点 的 
PVC 存 储 卷 空间 等 较 小 ， 而 且 在 启用 了 rbac 授 权 搬 件 的 集群 中 还 需要 创 
建 elasticsearch 所 需要 的 各 ClusterRole 及 ClusterRoleBinding 资 源 。 这 些 需 
要 有 自 定 义 的 配置 参数 可 以 通过 values 文 件 进 行 设置 ， 或 者 直接 由 “helm 
install” 命 令 的 “--set” 选 项 提供 。 一 个 示例 性 的 values 文 件 (els- 
values.yaml) 如 下 所 示 : 


# This is a YAML-formatted file. 
# Declare variables to be passed into your templates. 
appVersion: "5.5" 


image: 
repository: "centerforopenscience/elasticsearch" 
tag: "5.5" 
pullpPolicy: "IfNotPresent" 


cluster: 
name: "elasticsearch" 
config: 
env: 
MINIMUM_ MASTER_NODES: "2" 


client: 
name: client 
replicas: 2 
serviceType: ClusterIP 
heapSize: "2048m" 
antiAffinity: "soft" 
resources: 
limits: 
cpu: gg 
# memory: "8192Mi" 
requests: 
cpu: "25m" 


memory: "2048Mi" 


master: 
name: master 
exposeHttp: false 
replicas: 3 
heapSize: "2048m" 
persistence: 
enabled: true 
accessMode: Readwriteonce 
name: data 
size: "4Gi" 
#storageClass: "glusterfs" 
antiAffinity: "soft" 
resources: 
limits: 
cpu: ka 
# memory: "8192Mi" 
requests: 
cpu: "25m" 
memory: "2048Mi" 


data: 
name: data 
exposeHttp: false 
replicas: 2 
heapSize: "4096m" 
persistence: 
enabled: true 
accessMode: Readwriteonce 
name: data 
size: "120Gi" 
#storageClass: "glusterfs" 
terminationGracePeriodSeconds: 3600 
antiAffinity: "soft" 
resources: 
limits: 
cpu: kg 
# memory: "16384Mi" 
requests: 
cpu: "25m" 
memory: "4096Mi" 


## Install Default RBAC roles and bindings 
rbac: 
create: true 


需要 特别 说 明 的 是 ， 未 明确 定义 持久 存储 使 用 的 存储 类 时 ， 无 须 
持久 保存 数据 ， 或 者 无 可 用 的 实现 动态 供给 PV 的 存储 时 ， 也 可 以 使 用 
emptyDir 存 储 卷 ， 实 现 方法 是 将 上 面 示 例 中 masterpersistence.enabled 和 
data.persistence.enabled 配 置 参数 的 值 分 别 设置 为 "false”。 


名 提示 incubatorelasticsearch 相 关 的 配置 参数 列表 获取 地 址 为 


https://github.com/kubernetes/charts/tree/master/incubator/elasticsearch 。 


下 面 的 命令 oe 称 空间 中 部 署 ElasticSearch 和 集群 的 各 角色 及 
其 相关 的 其 他 资源 ， 其 通过 前 面 示 例 中 的 Values 文 件 els-values.yaml 获 
取 各 目 定义 的 配置 参数 : 


~]$ kubect1l create namespace logs 
~]$ helm install incubator/elasticsearch -n efk-els --namespace=logs -f els- 
values.yaml 


名 提示 仅 用 于 测试 ， 且 无 可 用 的 实现 动态 供给 PV 的 存储 类 
时 ， 则 无 须 定 义 Values 文 件 ， 并 将 上 面 的 命令 替换 为 "helm install 
incubator/elasticsearch-n efk-els--namespace=logs--set 
master.persistence.enabled="false", data.persistence.enabled="false", 
rbac.create= "true"” 即 可 。 


从 命令 最 后 提供 的 类 似 如 下 的 提示 信息 中 可 以 看 出 ， 部 署 完成 后 
在 Kubernetes 集 群 内 部 访问 ElasticSearch 服 务 的 接 入 端点 为 “efk- 
elasticsearch-client.logs.svc.cluster.local: 9200”。 随后 部 署 fluentd 时 将 基 
于 此 访问 端点 将 采集 到 的 日 志 导 入 到 ElasticSearch 集 群 中 ， 而 Kibana 也 
将 通过 此 端点 为 ElasticSearch 中 的 数据 提供 可 视 化 的 搜索 及 展示 接口 : 


NOTES : 
The elasticsearch cluster has been installed. 


Elasticsearch can be accessed: 
* Within your cluster, at the following DNS name at port 9200: 


efk-els-elasticsearch-client.1ogs.svc.cluster.local 


使 用 cirros 镜 像 创 建 一 个 测试 客户 问 ， 通 过 此 端点 对 ElasticSearch 的 
服务 发 起 测试 访问 请 求 。 例如 下 面 的 命令 可 用 0 求 显示 
ElasticSearch 集 群 的 欢迎 信息 : 


~]$ kubect1l run cirros-$RANDOM --rm -it --image=cirros -- sh 
/ # curl http://efk-els-elasticsearch-client.logs.svc.cluster.]local:9200 
{ 
"name"”: "efk-els-elasticsearch-client-55dccf5f75-7hhc9", 
"cluster_name" : "elasticsearch", 
"cluster_uuid" :; " uGffeD5bSo08q29v4uLaBw", 
"version" : { 


"number”: "5.5.2"， 


"build_hash" : "pb2fgoc09" ， 
"build_date" : "2017-08-14T12:33:14.154Z"， 
"build_snapshot" : false, 
"lucene version" :; "6.6.0" 
了 
"tagline" : "You Know, for Search" 
} 
/ # 


还 可 以 通过 类 似 如 下 的 命令 了 解 ElasticSearch 集 群 当 前 的 工作 状 
仿 ， 它 显示 出 当前 集群 处 于 正 利 工作 状态 “green”， 共 有 7 个 斑点 ， 其 中 
有 2 个 节点 为 数据 节点 。 由 于 是 新 创建 的 集群 ， 因 此 目前 尚 不 存在 任何 
数据 分 片 : 


/# curl http://efk-els-elasticsearch-client.logs.svc.cluster.local:9200/_cluster/ 
healthpretty 
{ 


"cluster_name" : "elasticsearch", 
"status" : "green", 

"timed _ out" : false, 
"number_of_nodes™" : 7, 
"number_of_data_nodes" : 2, 
"active_primary_shards" : 0, 
"active_shards" : 0, 


15.3.2 ”日志 采集 代理 fluentd 


fluentd 是 一 个 开源 的 数据 收集 器 ， 基 于 C 和 Ruby 语 言 开发 ， 它 目 
前 有 数 百 种 以 Ruby Gem 形 式 独立 存在 的 可 选 插件 ， 用 于 连接 多 种 数据 
源 和 数据 输出 组 件 等 ， 如 fluent-plugin-elasticsearch 插 件 用 于 实现 将 采 
集 到 的 数据 发 送 给 ElasticSearch 。 


@ 提示 fluentd 的 可 用 插件 列表 获取 地 址 为 


https:/www.fluentd.org/plugins 。 


运行 时 ， fnentd 人 天 重文 件 狼 取 数 据 源 数据 输出 目标 、 过 沽 硕 
等 相关 的 配置 信息 ， 这 些 配置 信息 以 source、match、filter、Ssystem、 
label 和 @include 配 置 参数 给 出 。 


Access logs Alerting 
Apache Nagios 


App logs Me a Analysis 
Frontend MongoDB 

Backend MySQL 

System logs # Cy ~、 Hadoop 
syslogd 


Archiving 
nia routing 
Databases Amazon S3 


图 15-6 fluentd 架 构 
source: 定义 数据 源 ， 每 个 数据 源 都 需要 有 其 专 有 类 型 的 定义 。 
match: 数据 输出 的 目标 位 置 ， 如 文件 或 各 种 存储 系统 。 


filter 过滤 絮 ， 即 事件 处 理 流水 线 ， 通 第 运行 于 输入 和 输出 之 
间 。 


system: 系统 级 设置 ， 如 处 理 器 名 称 等 。 
label: 用 于 分 组 过 滤器 及 输出 目标 。 


ee 引用 配置 信息 中 某 些 已 有 的 定义 ， 以 达到 配置 复 用 之 
目的 。 


下 面 的 配置 示例 中 给 出 了 fluentd 收 集 Kubernetes 平 台 上 容器 日 志 的 
输入 及 输出 相关 的 定义 : 


<source> 
@id fluentd-containers ,1og 
@type tail 
path /var/log/containers/*.1og 
pos_file /var/log/fluentd-containers.1o0g.pos 
time_format %Y-%m-%dT%H:%M:%S.%NZ 
tag raw.kubernetes.* 
format json 
read_from_head true 

</source> 

<match raw.kubernetes.**> 
Qid raw.kubernetes 
@type detect_ exceptions 
remove_tag_prefix raw 
message lo0og 
stream stream 
multiline_flush_interval 5 
max_bytes 500000 
max_lines 1000 

</match> 


incubator/fluentd-elasticsearch 是 Kubeapps 上 定义 的 基于 fluentd 收 集 
容器 及 系统 日 志 并 将 其 输出 至 ElasticSearch 中 的 Charts 之 一 ， 它 内 置 了 
基于 ConfigMap 资 源 定义 的 fluentd 配 置 文 件 ， 基 本 无 须 修改 即 能 投入 使 
用 。 男 外 ，fluentd 是 运行 于 各 节点 上 的 日 志 采 集 代 理 ， 因 此 ， 它 受 控 
于 DaemonSet 控 制 恬 。 


基于 此 Charts 部 署 fuentd 时 通 币 仅 需 为 其 指定 ElasticSearch 服 务 的 
访问 端点 即 可 ， 因 此 可 直接 基于 命令 局 动 部 署 操 作 : 


~]$ helm install local/fluentd-elasticsearch -n efk-flu --namespace=logs \ 
--Set elasticsearch.host="efk-els-elasticsearch- 


Client ,1ogs,.Svc.Cluster .Local" 


不 过 ， 寿 需要 收集 master 六 点 上 的 日 志 ， 束 需要 为 部 署 的 Pod 对 象 
添加 tolerations 以 容忍 master 上 的 taints。 修改 Charts 中 默认 的 values.yaml 
文件 中 的 配置 ， 并 以 之 完成 部 署 即 能 实现 。 


确认 fluentd 相 关 的 各 Pod 对 象 正 常 运行 之 后 ， 即 可 到 ElasticSearch 
集群 中 查看 其 收集 并 存储 的 日 志 的 索引 及 数据 信息 ， 例 如 ， 仍 于 此 前 
Re 查看 已 生成 的 索引 
命令 如 


/# curl http://efk-els-elasticsearch- 
client,.logs.svc.cluster.1local:9200/_cat/indices 

green open logstash-2018.06.10 UJtHdGeHTISVFkW8s0_PjQ 51 6 0 337.3kb 168.6kb 
green open logstash-2018.06.09 eotV9S2QQUCK1JUPENmieQ 5 1 47470 © 97.6mb 48.9mb 
/ # 


命令 结果 中 显示 出 以 “logstash-YYYY.MM.DD” 格 式 命名 的 索引 列 
表 ， 即 表示 fluentd 已 经 能 够 正常 采集 到 日 志 数 据 并 输出 到 指定 的 
ElasticSearch 和 集群 中 。 


15.3.3 “可视化 组 件 Kibana 


Kibana 是 ElasticSearch 的 数据 分 析 及 可 视 化 平台 ， 能 够 用 来 搜索 、 
查看 存储 在 Elastic-Search 索 引 中 的 数据 。 它 可 以 通过 各 种 图 表 进 行 高 级 
数据 分 析 及 展示 ， 用 户 基 于 Web GUI 可 以 快速 创建 仪表 板 

(dashboard) 实时 显示 ElasticSearch 的 查询 结果 。Kibana 配 置 过 程 简单 
便捷 ， 图 形 样式 丰富 ， 可 借助 于 ElasticSearch 创 建 柱 形 图 、 折 线 图 、 散 
点 图 、 直 方 图 、 饼 图 和 地 图 等 数据 展示 接口 。Kibana 增 强 了 
0 能 力 ， 让 用 户 能 够 更 加 智能 地 分 析 数 据 和 展示 


类 似 于 fluentd，Kibana 也 通过 URL 访 问 ElasticSearch， 但 它 要 通过 
环境 变量 ELASTIC-SEARCH_URL 来 指定 。 部 署 于 Kubernetes 上 的 
Kibana 一 般 会 由 集群 外 的 客户 端 访问 ， 因 此 需要 为 其 配置 Ingress 资 源 ， 
也 可 以 使 用 NodePort 或 LoadBalancer 类 型 的 Service 资 源 进 行 服务 又 露 。 
它 默 认 通 过 HTTP 提 供 服 务 ， 在 使 用 Ingress 暴 露 到 互联 网 时 ， 建 议 将 其 
配置 为 HTTPS 类 型 的 服务 。 


stable/kibana 是 Kubeapps 上 提供 的 Charts， 下 面 古 适用 于 当前 配置 环 
境 设 定 的 Values 文 件 (kibana-values.yaml) ， 它 使 用 镜像 文件 kibana: 
5.5 运 行 容器 ， 环 境 变 量 ELASTICSEARCH_URL 的 值 为 前 面部 署 的 
ElasticSearch 集 群 的 访问 接口 ， 并 通过 NodePort 类 型 的 Service 和 资源 进行 
服务 又 露 : 


Image : 
repository: "kibana" 
tag: "5.5" 
pullpPolicy: "IfNotPresent" 


env: 
ELASTICSEARCH_URL: http://efk-els-elasticsearch-client.1ogs.svc:9200 
SERVER_PORT: 5601 


service: 
type: NodePort 
externalPort: 443 
internalPort: 5601 


ingress: 
enabled: false 


而 后 ， 使 用 下 面 的 命令 即 可 完成 Kibana 部 署 : 


~]$ helm install stable/kibana -n efk-kib --namespace=logs -f kibana-values.yaml 
NAME : efk-kib 
LAST DEPLOYED: Sun Jun 10 09:19:49 2018 


RESOURCES : 

==> V1/Service 

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE 
efk-kib-kibana NodePort 10.110.201.6 <none> 443:30978/TCP 0s 


确认 相关 的 Pod 资 源 能 够 正常 运行 之 后 ， 即 可 通过 如 上 面 命令 显示 
的 Service 资 源 中 30978 端 口 于 集群 外 访问 Kibana， 其 初始 界面 如 图 15-7 
所 示 。 在 “Management” 中 添加 相应 的 索引 模式 加 载 相关 的 索引 数据 即 
可 完成 数据 搜索 及 可 视 化 配置 ， 由 fluentd 收 集 的 日 志 以 “logstash- 
YYYYMM.DD” 为 索引 名 根据 索引 产生 的 日 志 按 天 保存 于 单独 的 索引 
， 因 此 Kibana 默 认 的 模式 "logstash-*>” 便 能 够 加 载 这 些 索 引 中 的 数 


» © | © 17216.0.67:30978/app/kibanat/managementkibanay/index? g=0 
Management / Kibana 
Index Patterns Saved Objects Advanced Settings 


全 -外 
No oy Index pattern, You must select or create one to continue. 


Configure an index pattern 


In order to use Kibana you must configure at least one index pattern, Index patterns are used to identify the 
Elasticsearch index to run search and analytics against. They are also used to configure fields. 
Index name or pattern 


logstash-* 
Patterns allow you to define dynamic index names using * as a wildcard, Example; logstash-* 
Time Filter field name ©@ refresh fielos 
@timestamp 
Expand index pattern when searching [DEPRECATED]) 


With this option selected, searches against any time-based index pattern that contains a wildcard will automatically be 
expanded to query only the indices that contain data within the currenthy selected time range, 


Searching against the index pattern /ogstash-*will actually query Elasticsearch for the specific matching indices (e.g, /ogstash- 
2015.12.21 ) that fall within the current time range. 


With recent changes to Elasticsearch, thls option should no longer be necessary and will Iikely be removed In future versions of 
Kibana. 


Use event times to create index names [DEPRECATEDj] 


图 15-7 ”Kibana 的 初始 界面 


创建 好 索引 模式 之 后 ， 即 可 通过 “Discover” 搜 索 数 据 ， 或 者 
在 “Visualize” 界 面 中 定义 可 视 化 图 形 ， 并 将 它们 集成 于 可 
在 “Dashboard” 中 创建 的 仪表 板 里 。 


全) pans 得 序 (EChans) 的 版 本 号 不 能 高 
ElasticSearch， 否 则 会 导致 不 兼容 。 


15.4 本 草 小 结 


目前 来 说 ，Kubernetes 部 署 及 管理 应 用 程序 的 接口 仍然 相当 复 
杂 ， 在 维护 较 多 的 资源 时 ， 用 户 必 然 会 受 困 于 其 复杂 多 变 的 资源 配置 
清单 ，Helm 通 过 Charts 实 现 了 类 似 于 yum、dnf 或 apt-get 等 程序 包 管 理 
右 的 功能 ， 大 大 降低 了 用 户 的 使 用 成 本 。 本 章 详细 讲解 了 Helm 的 使 用 
方式 ， 并 通过 示例 演示 了 其 使 用 方法 。 


附 示 A ” 部署 Kubernetes 集 群 


A.1 准备 部 署 Kubernetes 集 和 群 


Kubernetes 项 目 目 前 仍然 处 于 快速 迭代 阶段 ， 演 示 过 程 中 使 用 的 配 
置 对 于 其 后 续 版 本 可 能 存在 某 些 变动 ， 因 此 ， 版 本 不 同时 ， 对 具体 特 
性 支持 的 变动 请 读者 参考 Kubermetes 的 ChangeLog 或 其 他 相关 文档 中 的 


说 明 。 


A.LL 部 署 目标 


图 A-1 给 出 了 本 和 要 部 署 的 目标 集群 的 基本 环境 ， 它 拥有 一 个 
Master 主 机 和 三 个 Node 主 机 。 各 Node 主 机 的 配置 方式 基本 相同 。 


Service 网 络 : 10.96.0.0/12 


master 


[ kube-controller-manager Pod ] 


kube-proxy Pod | kube-proxy Pod 


kube-scheduler Pod \ S 
kubelet Docker kubelet Docker kubelet Docker 
flannel Pod flannel Pod flannel Pod flannel Pod 


| 
入 点 网 络 : 172.16.0.0/16 


kube-proxy Pod 


Pod 网 络 : 10.244.0.0/16 


图 A-1 Kubernetes 集 群 部 署 目标 示意 图 


各 主机 上 采用 的 容器 运行 时 环境 为 Docker， 为 Pod 提 供 网 络 功能 的 
CNI 是 flannel， 它 运行 为 托管 于 Kubernetes 之 上 的 Pod 对 象 ， 另 外 ， 基 础 
附件 还 包括 KubeDNS (或 CoreDNS) 用 于 名 称 解析 和 服务 发 现 。 


A.1.2 系统 环境 及 部 署 准备 


如 前 所 述 ，Kubernetes 当 前 仍 处 于 快速 从 代 的 周期 中 ， 其 版 本 变化 
频 索 、 跨 版 本 的 特性 变化 较 大 ， 为 了 帮助 读者 确认 各 配 革 和 功能 的 可 
用 性 ， 本 书 使 用 如 下 基础 环境 。 

1. 各 相关 组 件 及 主机 环境 

操作 系统 、 容 器 引擎 、etcd 及 Kubernetes 的 相关 版 本 分 别 如 下 。 

‘OS: CentOS 7.5x86_64 

‘Container runtime: Docker 18.06.ce 

‘Kubernetes: 1.12 

各 主机 角色 分 配 及 IP 地 址 如 表 A-1 所 示 。 

表 A-1 Kubernetes 集 群 的 主机 环境 


Pi RE 
172.16.0.70 master. master.ilinux.i0 master 
172.16.0.66 node 
172.16.0.67 node 
172.16.0.68 node 

2. 基 础 环境 设置 


Kubernetes 的 正确 运行 依赖 于 一 些 基础 环境 的 设 定 ， 如 各 节点 时 间 
通过 网 络 时 间 服 务 保持 同步 和 主机 名 称 解 析 等 ， 集 群 规 模 较 大 的 实践 
场景 中 ， 主 机 名 称 解 析 通 常 由 DNS 服 务 妖 完成。 本 测试 示例 中 ， 时 间 
同步 服务 直接 基于 系统 的 默认 配置 从 互联 网 的 时 间 服 务 中 获取 ， 主 机 
名 称 解 析 则 由 hosts 文 件 进 行 。 


(1) 主机 名 称 解析 


分 布 式 系统 环境 中 的 多 主机 通信 通常 基于 主机 名 称 进 行 ， 这 在 IP 
地 址 存在 变化 的 可 能 性 时 为 主机 提供 了 固定 的 访问 入 口 ， 因 此 一 般 需 
要 有 专用 的 DNS 服 务 负 责 解 决 各 节点 主机 名 。 不 过 ， 考 虚 到 此 处 部 署 
的 是 测试 集群 ， 因 此 为 了 降低 系统 的 复杂 度 ， 这 里 将 采用 基于 hosts 的 
。 编辑 Master 和 各 Node 上 的 /etc/hosts 文 件 ， 确 保 
其 内 容 如 下 : 


172.16.0.66 node01.ilinux.io node01 


172.16.0.67 node02.ilinux.io node02 
172.16.0.68 node03.ilinux.io node03 
172.16.0.70 master. ilinux.io master 


(2) 主机 时 间 同 步 


如 采 各 主机 可 直接 访问 互联 网 ， 人 上 的 chronyd 服 
务 即 可 。 否 则 需要 使 用 本 地 网 络 中 的 时 间 服 务 器 ， 例 如 ， 可 以 将 Master 
配置 为 chrony server， 而 后 其 他 市 点 均 从 Master 辣 步 时 间 ， 


~]# Systemct1 start chronyd.service 
~]# Systemct1 enable chronyd,.service 


(3) 关闭 防火 墙 服务 


各 Node 运 行 的 kube-proxy 组 件 均 要 借助 ijptables 或 ipvs 构 建 Service 资 
源 对 象 ， 该 资源 对 象 是 Kubernetes 的 核心 资源 之 一 。 出 于 简化 问题 复 厅 
度 之 需 ， 这 里 需要 事先 关闭 所 有 主机 之 上 的 iptables 或 firewalld 服 务 : 


~]# Systemct1 stop firewalld. service iptables.service 
~]# systemctl1 disable firewalld.service 
~]# systemctl1 disable iptables.service 


(4) 关闭 并 禁用 SELinux 
若 当 前 启用 了 SELinux， 则 和 需要 临时 设置 其 当前 状态 为 


permissive: : 


~]# setenforce 0 


另外， 编辑 /etc/sysconfig/selinux 文 件 ， 以 彻 故 莹 用 SELinux: 


~]# sed -i 's@^\(SELINUX=\).*@\1disabled@' /etc/sysconfig/selinux 


(5) 禁用 Swap 设 备 〈 可 选 步骤 ) 


kubeadm 默 认 会 预 完 检查 当前 主机 是 否 禁 用 了 Swap 设 备 ， 并 在 未 
禁用 时 强制 终止 部 署 过 程 。 因 此 ， 在 主机 内 存 资源 充裕 的 条 件 下 ， 需 
要 禁用 所 有 的 Swap 设 备 。 


关闭 Swap 设 备 ， 和 需要 分 两 步 完 成 。 首 先是 关闭 当前 已 启用 的 所 有 


Swap 设 备 : 


~]#swapoff-a 


而 后 编辑 /etcfstab 配 置 文件 ， 注 释 用 于 挂 载 Swap 设 备 的 所 有 行 。 
不 同系 统 环境 默认 启用 的 Swap 设 备 不 尽 相 同 ， 请 读者 根据 实际 情况 完 
成 相应 操作 。 另 外 ， 部 署 时 也 可 以 选 不 禁用 Swap， 而 是 通过 后 文 的 
kubeadm init 及 kubeadm join 命令 执行 时 额外 使 用 相关 的 选项 名 略 检查 销 
误 。 


(6) 启用 ipvs 内 核 模 块 (可 选 步 又 ) 


Kubernetes 1.11 之 后 的 版 本 默认 支持 使 用 ipvs 代 理 模 式 的 Service 资 
产 ， 但 它 依赖 于 ipvs 相 关 的 内 核 模块 ， 而 这 些 模 块 默 认 不 会 目 动 载 入 。 
因此 ， 这 里 选择 创建 载 入 内 核 模 块 相关 的 脚本 文 
件 /etc/sysconfig/modules/ipvs.modules， 设 定 于 系统 引导 时 目 动 载 入 的 
2 的 内 核 模块 ， 以 文 持 使 用 ipvs 代 理 模式 的 Service 资 源 。 文 件 内 
容 如 下 : 


#!/bin/bash 
ipvs_mods_dir="/usr/lib/modules/$(uname -r)/kernel/net/netfilter/ipvs" 
for i in $(ls $ipvs mods_ dir | grep -0 "^[^.]*"); do 

/sbin/modinfo -F filename $i &> /dev/null 

if [$ -eq 0 ]; then 

/sbin/modprobe $i 

fi 

done 


而 后 ， 修 改 文件 权限 ， 并 手动 为 当前 系统 环境 加 载 内 核 模 块 : 


~]# chmod +x /etc/sysconfig/modules/ipvs.modules 
~]# /etc/sysconfig/modules/ipvs.modules 


不 过 ，ipvs 仅 负责 实现 负载 均衡 相关 的 任务 ， 它 无 法 完成 kube- 
proxy 中 的 包 过 滤 及 SNAT 等 功能 ， 这 些 仍 需要 由 iptables 实 现 。 另 外 ， 
对 于 初学 者 来 说 ， 前 期 的 测试 并 非 必然 要 用 到 ipvs 代 理 模 式 ， 部 署 时 可 
省 略 此 步骤 。 


A.2 部 署 Kubernetes 集 群 


kubeadm 是 用 于 快速 构建 Kubernetes 集 群 的 工具 ， 随 着 Kubernetes 的 
发 行 版 本 而 提供 ， 使 用 它 构建 集群 时 ， 大 致 可 分 为 如 下 几 步 。 


1) 在 Master 及 各 Node 安 装 Docker、kubelet 及 kubeadm， 并 以 系统 
守护 进程 的 方式 启动 Docker 和 kubelet 服 务 。 


2) 在 Master 节 点 上 通过 kubeadm init 命 令 进 行 集群 初始 化 。 
3) 各 Node 通 过 kubeadm join 命 令 加 入 初始 化 完成 的 集群 中 。 


4) 在 集群 上 部 署 网 络 附 件 ， 如 flannel 或 Calico 等 以 提供 Service 网 络 
及 Pod 网 络 。 


为 了 简化 部 署 过 程 ，kubeadm 使 用 一 组 固定 的 目 孙 及 文件 路 径 存储 
相关 的 配置 及 数据 文件 ， 其 中 /etc/kubernetes 目 录 是 所 有 文件 或 目录 的 
统一 存储 目 永 。 它 使 用 /etcwkubernetes/manifests 目 录 存 储 各 静态 Pod 资 源 
的 配置 清单 ， 用 到 的 文件 有 etcd.yaml 、kube-apiserver.yaml 、kube- 
controller-manager.yaml 和 kube-scheduler.yaml 四 个 ， 它 们 的 作用 基本 能 
够 见 名 知 义 。 男 外 ，/etc/kubernetes/ 目 录 中 还 会 为 Kubernetes 的 多 个 组 件 
存储 专用 的 kubeconfig 文 件 ， 如 kubelet.conf 、controller-manager.conf 、 
schedulerconf 和 admin.conf 等 ， 它 们 分 别 为 相关 的 组 件 提供 接 入 API 
Server 的 认证 信息 等 。 此 外 ， 它 还 会 在 /etc/kubernetes/pki 目 录 中 存储 奉 
干 私 钥 和 证 书 文件 。 


A.2.1 设 定 容器 运行 环境 


Kubernetes 支持 多 种 容器 运行 时 环境 ， 例 如 Docker、RKT 和 Frakti 
二 本 书 将 采用 其 中 目前 最 为 流行 的 、 接 受 程度 最 为 广泛 的 Docker， 
它 的 常用 部 署 方式 有 两 种 ， 具 体 如 下 。 


.由 系统 发 行 版 的 程序 包 仓 库 提 供 ， 如 Cent OS 7Extras 仓 库 中 的 


Docker ° 


.Docker 官 方 仓库 中 的 程序 包 ， 以 Cent OS 7 为 例 ， 它 通常 能 够 提供 
较 Extras 仓 库 中 更 新 版 本 的 程序 包 ， 获 取 地 址 为 


https://download.docker.com/ ° 


本 文采 用 的 是 第 二 种 方式 ， 不 过 ，Kubernetes 认 证 的 Docker 版 本 通 
党 略 低 于 其 最 新 版 本 ， 因 此 生产 环境 部 署 时 应 该 尽 可 能 部 署 经 过 认证 
的 版 本 。 考 虑 到 Kubernetes 厂 本 迭代 周期 较 短 ， 它 对 Docker 版 本 的 文 持 
也 会 快速 变化 ， 因 此 本 示例 将 直接 使 用 Docker 仓 库 中 的 最 新 版 本 。 部 
署 时 ，Docker 需 要 安装 于 Master 及 各 Node 主 机 之 上 上， 安装 方式 相同 ， 其 
步骤 如 下 : 


~]# wget https://download,.docker.com/linux/centos/docker-ce.repo \ 
-0 /etc/yum.repos.d/docker-ce.repo 
~]# yum install docker-ce 


QS 注意 。 kubeadm 构 建 集群 的 过 程 需要 到 gcrio 中 获取 Docker 镜 
像 ， 因 此 必须 确 傈 Docker 主 机 能 够 正常 访问 到 此 站 点 ， 否 则 ， 残 得 配 
置 Docker 以 代理 的 方式 访问 gcrio， 或 者 配置 kubeadm 从 其 他 Registry 获 
取 相 关 的 镜像 。 代 理 的 方法 是 在 [service] 配 置 段 中 添加 类 似 如 下 格式 的 
配置 项 ，Environment="HTTP_PROXY=http:/IP: PORT”， 或 
Environment="HTTPS_PROXY=https://IP: PORT”。 


另外 ，Docker 目 1.13 版 起 会 自动 设置 ptables 的 FORWARD 默 认 策 略 
为 DROP， 这 可 能 会 影响 Kubernetes 集 群 依赖 的 报 文 转发 功能 ， 因 此 ， 
需要 在 docker 服 务 启动 后 ， 重 新 将 FORWARD 链 的 默认 策略 设置 为 
ACCEPT， 方 式 是 修改 /usYlib/systemd/systemy/docker.service 文 件 ， 
在 “ExecStart=/usrbin/dockerd” 一 行 之 后 新 增 一 行 如 下 内 容 : 


ExecStartPost=/usr/sbin/iptables -P FORWARD ACCEPT 


上 面 各 步骤 设置 完成 后 即 可 局 动 docker 服 务 ， 并 将 其 设置 为 随 系统 
引导 而 目 动 启用， 相关 命令 如 下 : 


~]# Systemct] daemon-reload 
~]# systemctl start docker.service 
~]# systemct] enable docker.service 


@ 提示 国内 访问 DockerHub 下 载 镜像 的 速度 较 缓 慢 ， 建 议 使 
用 国内 的 镜像 对 其 进行 加 速 ， 如 https://registry.docker-cn.com ， 男 外 ， 
中 国 科技 大 学 也 提供 了 公共 可 用 的 镜像 加 速 服务 ， 其 URL 为 
https://docker.mirrors.ustc.edu.cn ， 将 其 定义 在 daemon.json 中 重启 Docker 
即 可 使 用 。 


A.2.2” 设 定 Kubernetes 集 群 节点 


kubelet 是 运行 于 集群 中 每 个 节点 之 上 的 Kubernetes 代 理 程序 ， 它 的 
核心 功能 在 于 通过 API Server 获 取 调 度 至 自 映 运行 的 Pod 资 源 的 PodSpec 
并 依 之 运行 Pod 对 象 。 事 实 上 ， 以 自 托 管 方 式 部 署 的 Kubernetes 集 群 ， 
除了 kubelet 和 Docker 之 外 的 所 有 组 件 均 以 Pod 对 象 的 形式 运行 。 


1. 安 装 kubelet 及 kubeadm 


安装 kubelet 的 常用 方式 包含 如 下 几 种 。 快 速 迭代 期 内 ，Linux 发 行 
商 提 供 的 安 效 包 通常 版 本 较 低 ， 因 此 建议 采用 下 列 方式 的 第 一 种 或 第 
二 种 ， 本 章 将 采用 第 二 种 方式 。 


:Kubernetes 提 供 的 二 进 制 格 式 的 tar 包 。 


Google 的 yum 仓 库 中 提供 的 mpm 包 ， 可 通过 国内 的 镜像 站 点 获取 ， 
例如 阿里 云 镜 像 站 。 


.0S 发 行商 提供 的 安装 包 ， 例 如 Cent OS 7Extras 仓 库 中 的 Kubernetes 
相关 程序 包 。 


名 提示 “对 于 rpm 方 式 的 安装 来 说 ，kubelet、kubeadm 和 
kubectl 等 是 各 上 自 独 立 的 程序 包 ，Master 及 各 Node 至 少 应 该 安装 kubelet 和 
kubeadm， 而 kubect 则 只 需要 安装 于 客户 端 主 机 即 可 ， 不 过 ， 由 于 依赖 
关系 它 通常 也 会 被 目 动 安装 。 另 外 ，Google 提 供 的 kubelet rpm 包 的 yum 
仓库 托管 于 Google 站 点 的 服务 右 主 机 之 上 ， 目 前 访问 起 来 略 有 不 便 。 


邓 运 的 是 ， 目 前 国内 的 阿里 云 等 镜像 〈http:/mirrors.aliyun.com ) 对 此 
项 目 也 有 镜像 提供 。 


首先 设 定 用 于 安装 kubelet、kubeadm 和 kubectl 等 组 件 的 yum 仓 库 ， 
编辑 配置 文件 /etcyum.repos.d/kubernetes.repo， 内 容 如 下 : 


[kubernetes] 

name=Kubernetes 

baseurl= https://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64/ 

enabled=1 

gpgcheck=1 

repo_gpgcheck=1 

gpgkey= https://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg https:// 
mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-key.gpg 


而 后 执行 如 下 命令 即 可 安装 相关 的 程序 包 : 


[root@master ~]# yum install kubelet kubeadm kubectl 


2. 配 置 kubelet 
Kubernetes 目 1.8 版 本 起 强制 要 求 关闭 系统 上 的 交换 分 区 
(Swap) ， 否 则 kubelet 将 无 法 启动 。 当 然 ， 用 户 也 可 以 通过 将 kubelet 
的 启动 参数 “--fail-swap-on” 设 置 为 “false” 忽 上 略 此 限制 ， 尤 其 是 系统 上 运 
行 有 其 他 重要 进程 昌 系 统 内 存 资源 稍 嫌 不 足 时 建议 保留 交换 分 区 。 


编辑 kubelet 的 配置 文件 /etc/sysconfig/kubelet， 设 置 其 配置 参数 如 
下 ， 以 忽略 禁止 使 用 Swap 的 限制 : 


KUBELET_EXTRA_ARGS="--fail-swap-on=false" 


待 配置 文件 修改 完成 后 ， 需 要 设 定 kubelet 服 务 开机 自动 局 动 ， 这 
也 是 kubeadm 的 强制 要 求 : 


[root@master~]#systemctl1 enable kubelet.service 


A.2.3 ”集群 初始 化 


一 旦 Master 和 各 Node 的 Docker 及 kubelet 设 置 完 成 后 ， 接 着 便 可 以 在 
Master 节 点 上 执行 “kubeadm init” 命 令 进 行 集 群 初始 化 。kubeadm init 命 
令 文 持 两 种 初始 化 方式 ， 一 是 通过 命令 行 选 项 传递 关键 的 参数 设 定 ， 

妨 一 个 是 基于 yaml 杠 式 的 记 用 配置 文件 设 定 更 详细 的 配置 参数 。 下 面 
分 别 给 出 了 两 种 实现 方式 的 配置 步骤 ， 建 议 读者 采用 第 二 种 方式 。 


Master 初 始 化 方式 一 : 运行 下 面 的 命令 ， 便 可 完成 Master 的 初始 


[root@master ~]# kubeadm init \ 
--kubernetes-version=v1.12.1 \ 
--pod-network-cidr=10.244.0.0/16 \ 
--Service-cidr=10.96.0.0/12 \ 
--apiserver-advertise-address=0.0.0.0 \ 
--ignore-preflight-errors=Swap 


上 面 命令 的 选项 及 参数 设 定 决定 了 集群 运行 环境 的 众多 特性 设 
定 ， 这 些 设 定 对 于 此 后 在 集群 中 部 署 运行 应 用 程序 至 关 重 要 。 


.--kubernetes-version: 正在 使 用 的 Kubernetes 程 序 组 件 的 版 本 号 ， 
需要 与 kubelet 的 版 本 号 相同 。 


.--pod-network-cidr: Pod 网 络 的 地 址 范围 ， 其 值 为 CIDR 格 式 的 网 络 
地 址 ; 使 用 flannel 网 络 插件 时 ， 其 默认 地 址 为 10.244.0.0/16 。 


.--Service-cidr: Service 的 网 络 地 址 范围 ， 其 值 为 CIDR 格 式 的 网 络 
地 址 ， 默 认 地 址 为 10.96.0.0/12 。 


.--apiserver-advertise-address: API server 通 告 给 其 他 组 件 的 IP 地 
址 ， 一 般 应 该 为 Master 节 点 的 IP 地 址 ，0.0.0.0 表 示 方 点 上 所 有 可 用 的 地 
址 。 


--ignore-preflight-errors: 忽略 哪些 运行 时 的 错误 信息 ， 其 值 为 
Swap 时 ， 表示 忽略 因 swap 未 关闭 而 导致 的 错误 。 


@ 更 多 的 参数 请 参考 kubeadm 的 文档 ， 链 接地 址 为 


https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-init/ 。 


Master 初 始 化 方式 二 : kubeadm init 也 可 通过 配置 文件 加 载 配置 ， 
以 定制 更 丰富 的 部 署 选 项 。 以 下 是 符合 前 述 命令 设 定 方式 的 使 用 示 
例 ， 不 过 ， 它 明确 定义 了 kubeProxy 的 模式 为 jpvs， 并 支持 通过 修改 
imageRepository 的 值 来 修改 获取 系统 镜像 时 使 用 的 镜像 仓库 。 


apiVersion: kubeadm.k8s.io/vialpha2 
kind: MasterConfiguration 
kubernetesVersion: v1.12.1 
api: 
advertiseAddress: 172.20.0.70 
bindPort: 6443 
controlPplaneEndpoint: "" 
imageRepository: k8s.gcr.io 
kubeProxy: 
config: 
mode: "ipvs" 
ipvs: 
ExcludeCIDRs: null 
minSyncPeriod: Os 
scheduler: "" 
syncPeriod: 30s 
kubeletCconfiguration: 
baseConfig: 
cgroupDriver: cgroupfs 
ClusterDNS : 
- 10.96.0.10 
clusterDomain: Cluster .1ocal 
failSwapon: false 
resolvConf: /etc/resolv.conf 
StaticPodPath: /etc/kubernetes/manifests 
networking: 
dnsDomain: cluster.local 
podSubnet: 10.244.0.0/16 
serviceSubnet: 10.96.0.0/12 


将 上 面 的 内 容 保 存 于 配置 文件 中 ， 如 kubeadm-config.yaml， 而 后 执 
行 相应 的 命令 即 可 完成 Master 初 始 化 : 


~]# kubeadm init --config kubeadm-config.yaml --ignore-preflight-errors=Swap 


无 论 使 用 上 述 哪 种 方法 ， 命 令 的 执行 过 程 都 会 执行 众多 部 署 操作 
并 生成 相关 的 信息 ， 如 生成 配置 文件 ， 标 识 主 巴 点 、 生 成 bootstrap 
token 及 部 署 核心 附加 组 件 kube-proxy 和 kube-dns 等 ， 尤 其 是 为 集群 通信 
安全 于 /etc/kubernetes/pki 目 孙 中 生 成 的 一 众 密 钥 和 数字 证 书 ， 并 在 最 后 
给 出 了 kubect 客 户 端 工 具 的 配置 文件 生成 方式 以 及 随后 将 Node 加 入 集 
群 时 使 用 的 引导 认证 令 牌 (bootstrap token) 等 ， 后 续 需 要 加 入 集群 的 
各 Node 都 将 使 用 该 引导 认证 令 牌 加 入 集群 。 不 同 版 本 的 kubeadm 其 输出 


结 采 或 许 略 有 不 同 。 本 示例 特定 将 需要 注意 的 部 分 以 粗 体 格式 予以 标 
识 ， 它 们 十 后 续 步 又 的 重要 提示 信息 。 命 令 执行 的 结 末 如 下 所 示 : 


[addons] Applied essential addon: CoreDNS 
[addons] Applied essential addon: kube-proxy 


Your Kubernetes master has initialized successfully! 
To start using your cluster, you need to run the following as a regular user: 


mkdir -p $HOME/.Kkube 
sudo cp -i /etc/kubernetes/admin.conf $HOME/.Kkube/config 
sudo chown $(id -u):$(id -g) $HOME/.Kkube/config 


You should now deploy a pod network to the cluster. 
Run "kubectl1 apply -f [podnetwork].yaml" with one of the options listed at: 
https://kubernetes.io/docs/concepts/cluster-administration/addons/ 


You can now join any number of machines by running the following on each node 
as root: 


kubeadm join 172.16.0.70:6443 --token sgm8ht.dxhqol0042i52fnz --discovery- 
token-ca- 
cert-hash 
sha256 :ffco0304409012dacbo7edbe886e36b4215cff94fa5cd48eee2f55c91e65b0a01 


根据 上 述 输出 信息 的 提示 〈 粗 体 部 分 | ， 完 成 集群 部 署 还 需要 执 
行 三 类 操作 : 设 定 kubecd 的 配置 文件 、 部 署 网 络 附件 以 及 将 各 Node 加 
入 集群 。 下 面 束 来 讲解 如 何 进行 这 三 步 操作 。 


A.2.4” 设 定 kubectl 的 配置 文件 


kubectl 是 执行 Kubernetes 集 群 管理 的 核心 工具 。 默 认 情 况 下 ， 
kubectl 会 从 当前 用 户主 目录 〈 保 存 于 环境 变量 HOME 中 的 值 ) 中 的 隐 
蔬 目 录 .kube 下 名 为 config 的 配置 文件 中 读 取 配 置信 息 ， 包 括 要 撑 入 
Kubernetes 集 群 、 以 及 用 于 集群 认证 的 证 书 或 令 牌 等 信息 。 集 群 初始 化 
时 ，kubeadm 会 目 动 生成 一 个 用 于 此 类 功能 的 配置 文 
件 /etc/kubernetes/admin.conf， 将 它 复 制 为 用 户 的 $4HOME/.kube/config 文 
件 即 可 直接 使 用 。 这 里 以 MasterT 点 上 的 root 用 户 为 例 进 行 操作 ， 不 
过 ， 在 实践 中 应 该 以 普通 用 户 的 身份 进行 


[root@master ~]# mkdir -p $HOME/ ,Kube 
[root@master ~]# cp -i /etc/kubernetes/admin.conf $HOME/.Kkube/config 


至 此 为 止 ， 一 个 Kubernetes Master 节 点 已 经 基本 配置 完成 。 接 下 来 
即 可 通过 API Server 来 验证 其 各 组 件 的 运行 是 否 正 常 。kubectl/ 有 着 众多 
子 命 令 ， 其 中 “get compontsstatuses” 即 能 显示 出 集群 组 件 当 前 的 状态 ， 
也 可 使 用 其 简写 格式 “get cs”: 


[root@master ~]# kubectl get cs 


NAME STATUS MESSAGE ERROR 
scheduler Healthy ok 
controller-manager Healthy ok 

etcd-0 Healthy {"health": "true"} 


若 上 面 命令 结果 的 STATUS 字段 为 "Healthy”， 则 表示 组 件 处 于 健康 
运行 状态 ， 否 则 需要 检查 其 错误 所 在 ， 必 要 时 可 使 用 “kubeadm reset” 命 
令 重 置 之 后 重新 进行 集群 初始 化 。 


另外， 使 用 “kubectl get nodes” 命 令 能 够 获取 集群 节点 的 相关 状态 信 
息 ， 如 下 命令 结果 显示 了 Master 闻 点 的 状态 为 “NotReady”( 未 就 绪 ) ， 
这 是 因为 集群 中 尚未 安装 网 络 插件 所 致 ， 执 行 完 后 面 的 其 他 步 又 后 它 
即 目 行 转 为 *Ready”: 


[root@master ~]# kubect] get nodes 
NAME STATUS ROLES AGE VERSION 
master .ilinux.io NotReady master 4m V1.12.1 


A.2.5 部署 网 络 插件 


为 Kubernetes 提 供 Pod 网 络 的 搬 件 有 很 多 ， 目 前 最 为 流行 的 是 
flannel 和 Calico。 相 比较 来 说 ，flannel 以 其 简单 、 易 部 署 、 易 用 等 特性 
广 受 用 户 欢 迎 。 基 于 kubeadm 部 署 时 ，flannel 同 样 运行 为 Kubernetes 集 
群 的 附件 ， 以 Pod 的 形式 部 署 运行 于 每 个 集群 入 点 上 以 接受 Kubernetes 
集群 管理 。 事 实 上 ， 也 可 以 直接 将 flannel 程 序 包 安装 并 以 守护 进程 的 方 
式 运行 于 集群 太 点 上 ， 即 以 非 托 管 的 方式 运行 。 部 署 方式 既 可 以 是 获 
取 其 资源 配置 清单 于 本 地 而 后 部 署 于 集群 中 ， 也 可 以 直接 在 线 进行 应 
用 部 署 。 部 署 命 令 是 “kubectl apply” 或 “kubectl create”， 例 如 ， 下 面 的 命 
令 将 直接 使 用 在 线 的 配置 清单 进行 fannel 部 署 : 


[root@master ~]# kubectl apply -f 
https://raw.githubusercontent.com/coreos/flannel/ 


master/Documentation/kube-flannel.yml 


kubectl 可 根据 定义 资源 对 象 的 清单 文件 将 其 提交 给 API Server 以 管 
理 资 源 对 象 ， 如 使 用 “kubectl apply-f/PATH/TO/MANIFEST”* 命 令 即 可 根 
据 清单 设置 资源 的 目标 状态 。kubectl 的 具体 使 用 会 在 后 面 的 章节 进行 


详细 介绍 。 


配置 fannel 网 络 插件 时 ，Master 世 点 上 的 Docker 首 先 会 去 获取 
flannel 的 镜像 文件 ， 而 后 根据 镜像 文件 启动 相应 的 Pod 对 象 。 待 其 运行 
完成 后 再 次 查看 集群 中 的 节点 状态 可 以 看 出 Master 已 经 变 为 “<Ready” 状 


4D。 


[root@master ~]# kubect1 get nodes 
NAME STATUS ROLES AGE VERSION 
master .ilinux.io Ready master 10m Vi 125 


@ 提示 ”kube-system|grep flannel” 命 令 的 结果 显示 Pod 的 状态 为 
Running 时 即 表 示 网 络 插件 flannel 部 署 完成 。 


A.2.6 添加 Node 至 集群 中 


Master 各 组 件 运 行 正 背后 即 可 将 各 Node 添 加 至 集群 中 。 配 置 世 点 
上 时， 需要 事先 参考 前 面 “设置 容器 运行 环境 ”和 “ 设 定 Kubernetes 集 群 广 
点 ”两 节 中 的 配置 过 程 设置 好 Node 主 机 ， 而 后 即 可 在 Node 主 机 上 使 
用 “kubeadm joim”* 命 令 将 其 加 入 集群 中 。 不 过 ， 为 了 系统 安全 起 见 ， 任 
何 一 个 试图 加 入 到 集群 中 的 节点 都 需要 先 经 由 API Server 完 成 认证 ， 其 
认证 方法 和 认证 信息 在 Master 上 运行 的 “kubeadm init* 命 令 执行 初始 化 
时 将 于 输出 结果 信息 的 最 后 一 部 分 中 提供 。 


例如 ， 类 似 如 下 命令 即 可 将 node01.ilinux.io 加 入 集群 中 ， 它 使 用 集 
群 初始 化 时 生成 的 认证 令 牌 (token) 信息 进行 认证 。 另 外 ， 同 样 出 于 
为 操作 系统 及 其 他 应 用 保留 交换 分 区 之 目的 ， 在 kubeadm join 命令 上 添 
加 了 “--ignore-preflight-errors=Swap” 选 项 : 


[root@node01 ]# kubeadm join 172.16.0.70:6443 --ignore-preflight-errors=Swap 
--token sgm8ht.dxhqol0042i52fnz --discovery-token-ca-cert-hash \ 


sha256 :ffc0304409012dacbo7edbe886e36b4215cff94fa5cd48eee2f55c91e65b0a01 


提供 给 API Server 的 bootstrap token 认 证 完成 后 ，kubeadm join 命令 
会 为 后 续 Master 与 Node 组 件 间 的 双 回 ssyds 认 证 生成 私 钥 及 证 书签 署 请 
求 ， 并 由 Node 在 首次 加 入 集群 时 提交 给 Master 咒 的 CA 进 和 J 丛 冰 。 默认 
情况 下 ，kubeadm 配 置 kube-apiserver 启 用 J bootstrapTL S 功 能 ， 并 文 持 
证 书 的 目 动 签署 。 于 是 ，kubelet 及 kube-proxy 等 组 件 的 相关 私 铀 和 证 书 
文件 在 命令 执行 结束 后 便 可 自动 生成 ， 它 们 默认 保存 
于 /var/lib/kubelet/pki 目 录 中 。 


在 每 个 太 点 上 重复 上 壕 步 又 束 能 够 将 其 加 入 集群 中 。 所 有 节点 加 
入 完成 后 ， 即 可 使 用 "kubectl get nodes” 命 令 验 证 集群 的 节点 状态 ， 包括 
各 节点 的 名 称 、 状 态 就 绪 与 否 、 角 色 〈 是 否 为 节点 Master) 、 加 入 集群 
的 时 长 以 及 程序 的 版 本 等 信息 : 


[root@master ~]# kubect] get nodes 


NAME STATUS ROLES AGE VERSION 
master .ilinux.io Ready master 25m V1.12.1 
node01.ilinux.io Ready <none> 1m V1.12.1 
node02.ilinux.io Ready <none> 1m V1.12.1 
node03.ilinux.io Ready <none> 32S V1.12.1 


到 此 为 止 ， 使 用 kubeadm 构 建 Kubernetes 集 群 已 经 完成 。 后 续 若 有 
Node 需 要 加 入 ， 其 方式 均 可 使 用 此 节 介 绍 的 方式 来 进行 。 


A.2.7 获取 集群 状态 信息 


Kubernetes 集 群 以 及 部 署 的 插件 提供 了 多 种 不 同 的 服务 ， 如 此 前 部 
署 过 的 API Server、kube-dns 等 。API 客 户 端 访问 集群 时 需要 事先 知道 
API Server 的 通告 地 址 ， 管 理 员 可 使 用 “kubectl cluster-info> 命 令 了 解 到 
这 些 信息 /EN : 


[root@master ~]# kubect1 cluster-info 

Kubernetes master is running at https://172.16.0.70:6443 

CoreDNS is running at https://172.16.0.70:;6443/api/vi/namespaces/kube-system/ 
services/kube-dns:dns/proxy 


Kubernetes 集 群 Server 端 和 Cjlient 端 的 版 本 等 信息 可 以 使 用 “kubectl 


version”* 命 令 进 行 查 看 : 


[root@master ~]# kubectl version --Short=true 
Client Version: v1.12.1 
Server Version: v1.12.1 


A.3 ”从 集群 中 移 除 太 扣 


运行 过 程 中 ， 帮 有 节点 需要 从 正常 运行 的 集群 中 移 除 ， 则 可 使 用 
如 下 步 又 来 进行 。 


1) 在 Master 上 使 用 如 下 命令 “ 排 干 ”( 迁 移 至 集群 中 的 其 他 节点 ) 
当前 节点 之 上 的 Pod 资 源 并 移 除 Node 节 点 : 


~]# kubectl] drain NODE_ID --delete-local-data --force --ignore-daemonsets 
~]# kubect] delete node NODE_ID 


me” ee 而 后 在 要 删除 的 Node 上 执行 如 下 命令 重 置 系统 状态 便 可 完成 移 
余 操 作 : 


~]# kubeadm reset 


A.4 重新 生成 用 于 节点 加 入 集群 的 认证 命令 


如 果 忘 记 了 记录 Master 主 机 的 kubeadm init 命 令 执 行 结果 中 用 于 让 
节点 加 入 集群 的 kubeadm join 命 令 及 其 认证 信息 ， 则 需要 分 别 通 过 
kubectl 获 取 认 证 令 牌 及 验证 CA 公 钥 的 哈 希 值 。 


“kubeadm token list” 能 够 获取 到 集群 上 存在 认证 令 牌 ， 定 位 到 其 中 
DESCRIPTION 字段 中 标识 为 由 *kubeadm init” 命 令 生 成 的 行 ， 其 第 一 字 
段 TOKEN 中 的 令 牌 即 为 认证 令 牌 。 而 验证 CA 公 钥 的 哈 硕 值 

(discovery-token-ca-cert-hash) 的 获取 命令 则 略微 复杂 ， 其 完成 格式 如 
下 所 示 : 


~]# openssl] x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl [Sa -pubin 
-outform der 2>/dev/null | openssl dgst -sha256 -hex | sed 's/ 人 人, 


人 人 


而 后 ， 将 上 述 两 个 命令 生成 的 结果 合成 为 如 下 格式 的 kubeadm join 
命令 即 可 用 于 让 Node 加 入 集群 中 ， 其 中 的 TOKEN 可 等 换 为 上 面 第 一 个 
命令 的 生成 结果 ，HASH 可 替换 为 第 二 个 命令 的 生成 结 


kubeadm join 172.16.0.70:6443 --token TOKEN --discover-token-ca-cert-hash HASH 


最 后 ， 需 要 提醒 读者 注意 的 是 ，Kubernetes 项 目 目 前 处 于 快速 迭代 
十 期 ， 其 版 本 号 演进 速度 较 快 ， 因 此 ， 读 者 在 测试 时 默认 安装 的 程序 
版 本 与 本 书 使 用 的 极 有 可 能 存在 着 不 同 ， 甚 至 连 部 署 步骤 都 可 能 会 发 


生 改 变 。 建 议 读者 参考 作者 的 微 信 公众 号 还 ubernetes 以 获取 较 新 的 部 署 
文档 ， 微 信 公 众 号 二 维 码 如 下 。 


附 示 B ”部署 GlusterFS 及 Heketi 


在 实践 Kubernetes 的 StatefulSet 及 各 种 需要 持久 存储 数据 的 组 件 或 
功能 时 ， 通 常会 用 到 PV 的 动态 供给 功能 ， 这 就 需要 用 到 支持 此 类 功能 
的 存储 系统 。 在 各 类 文 持 PV 动态 供给 功能 的 存储 系统 中 ，GlusterFS 的 
设 定 较 为 简单 ， 因 此 本 书 用 到 的 各 类 动态 存储 功能 将 以 此 为 例 进行 说 
明 。 本 章 将 试图 为 读者 提供 一 个 设置 以 满足 此 功能 的 GlusterFS 存 储 系 
统 的 简单 说 明文 档 ， 而 不 是 对 GlusterFS 进 行 全 面 介 绍 。GlusterFS 的 以 


构 如 图 B-1 所 示 。 


GlusterFS Global Namespace hostname:/share 


En 
GlusterFS Volumes i 


REST 
clients 


图 B-1 ”GlusterFS 架 构 


本 示例 中 ，gfs01.ilinux.io、gfs02.ilinux.io 和 gfs03.ilinux.io 三 个 万 点 
组 成 了 GlusterFS 存 储 集群 (如 图 B-1 所 示 ) ， 并 将 gfs01 节 点 部 署 为 
heketi 服 务 器 。 各 节点 上 ，sdb、sdc 和 和 sdd 用 于 为 GlusterFS 提 供 存储 空 
间 。 


B.1 部 署 GlusterFS 集 群 


首先 ， 分 别 在 三 个 节点 上 安装 glusterfs-server 程 序 包 ， 并 局 动 


glusterfsd 服 务 ， 命 令 如 下 : 


# yum install centos-release-gluster 
# yum --enablerepo=centos-gluster*-test install glusterfs-server 
# systemctl1 start glusterd.service 


第 二 步 ， 在 任 一 五所 上 使 用 "gusterfs peer probe” 命 令 “ 发 现 ” 其 他 节 
点 ， 组 建 GlusterFS 集 群 ° 命令 格式 为 “peer probe{<HOSTNAME>|<IP- 
address>}”， 例 如 ， 在 gfs01 上 运行 如 下 命令 : 


[root@gfs01 ~]# gluster peer probe gfs02.,ilinux.io 
[root@gfs01 ~]# gluster peer probe gfs03.ilinux.io 


第 三 步 ， 通 过 节点 状态 命令 “gluster peer status” 人 确认 各 节点 已 经 加 
入 同一 个 可 信 池 中 (trusted pool) 


[root@gfs01 ~]# gluster peer status 
Number of Peers: 2 


Hostname: 172.16.2.37 

Uuid: egof7e3cf-f856-4f95-a7d9-ad2e99cc455b 
State: Peer in Cluster (Connected) 

Other names : 

gfs02.ilinux.io 


Hostname: 172.16.2.38 

Uuid: a1025d59-ac33-4265-a4d8-667b2d8a3a5c 
State: Peer in Cluster (Connected) 

Other names : 

gfs03.ilinux.io 


B.2 ”部署 Heketi 


Heketi 为 管理 GlusterFS 存 储 卷 的 生命 周期 提供 了 一 个 RESTful 管 理 
接口 ， 借 助 于 Heketi， 像 OpenStack Manila、Kubernetes 和 OpenShift 文 样 
的 云 服务 可 以 动态 调配 Gluster 存 储 卷 。Heketi 能 够 自动 确定 整个 集群 的 
brick 位 置 ， 并 确保 将 brick 及 其 副本 放置 在 不 同 的 故障 域 中 。 男 外 ， 
0 Gluster 存 储 集群 ， 并 文 持 云 服务 提供 网 络 文件 
了 O 


有 了 Heketi， 存 储 管理 员 不 必 再 管理 或 配置 brick、 磁 盘 或 可 信和 存储 
池 (trusted pool) ，Heketi 服 务 将 为 管理 员 管 理 所 有 人 硬件， 并 使 其 能 够 
按 需 分 配 存储 。 不 过 ， 在 Heketi 中 注册 的 任何 磁 副 都 必须 以 原始 格式 提 
供 ， 而 不 能 是 创建 过 文件 系统 的 磁盘 分 区 。Heketi 架 构 如 图 B-2 所 示 。 


SERVICE 
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[二 可 
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NODE 1 NODE 7 
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NODE 3 NODE9 
2 Zone 2 
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图 B-2 Heketi 架 构 


本 部 署 示例 将 gfs01.ikubernees.io 廊 点 用 作 Heketi 服 务 器 ， 因 此 以 下 
所 有 步 又 均 在 gfs01 上 执行 。 


B.2.1 安装 并 启动 Heketi 服 务 


首先 安装 Heketi。Heketi 程 序 可 于 epel 仓 库 中 获取 ， 配 置 好 相关 的 
仓库 后 即 可 运行 如 下 安装 命令 : 


[root@gfs01~]#yum install heketi heketi-client 


第 二 步 ， 配 置 Heketi 用 户 能 够 基于 SSH 密 钥 的 认证 方式 连接 人 至 
GluserFS 集 群 中 的 各 下 点 ， 并 拥有 相应 下 点 的 管理 权限 : 


# ssh-keygen -f /etc/heketi/heketi key -t rsa -N '' 
# chown heketi:heketi /etc/heketi/heketi key* 
# for host in gfs01 gfs02 gfs03; do \ 
ssh-copy-id -i /etc/heketi/heketi key.pub root@${host}.ilinux.io; done 


第 三 步 ， 设 置 Heketi 的 主 配置 文件 /etc/heketi/heketi.json， 定 义 服 务 
a 、 认 证 及 连接 Gluster 存 储 集 群 的 方式 。 一 个 配置 示例 如 


"port": "8080", 
"use_auth": false, 


"jwt": { 
"admin": { 
"key": "admin Secret" 
x 
"user": { 
"key": "user Secret" 


x 
"glusterfs": { 


"executor": "ssh", 

"sshexec": 
"keyfile": "/etc/heketi/heketi key", 
"User": "root", 


"port": "22", 
"fstab": "/etc/fstab" 


}, 
"db": "/var/lib/heketi/heketi.db", 
"loglevel": "debug" 


若 要 启用 连接 Heketi 的 认证 ， 则 需要 将 “use_auth” 参 数 的 值 设 置 
为 “true”， 并 在 “jwt{}? 配 置 段 中 为 各 用 户 设 定 相应 的 密码 ， 用 户 名 和 蜜 


码 都 可 以 目 定 义 。“glusterfs{}” 配 置 段 用 于 指定 接 入 Gluster 存 储 集群 的 
认证 方式 及 认证 信息 。 


@ 若 启 用 了 认证 功能 ， 则 于 Kubernetes 集 群 中 配置 存储 
类 时 需要 设置 相应 的 认证 信息 。 


第 四 步 ， 启 动 Heketi 服 务 : 


# systemctl1 enable heketi 
# systemctl1 start heketi 


需要 注意 的 是 ， 将 Gluster 存 储 集群 的 功能 托管 于 Heketi 之 后 便 不 能 
0 中 使 用 命令 管理 存储 着， 以 免 与 Heketi 效 据 库 中 存储 的 信息 


第 五 步 ， 问 Heketi 发 起 访问 测 斌 请求， 无须 认证 时 ， 使 用 cunl 命 令 
即 能 完成 测试 : 


# curl http://gfs01:8080/hello 
Hello from Heketi 


者 Heketi 局 用 了 认证 功能 ， 则 需要 使 用 heketi-cli 命 令 进行 测试 ， 命 
令 格式 如 下 : 


heketi-cli --server http://<server:port> --user <user> --Secret <secret> cluster 
list 


B.2.2 ”设置 Heketi 系 统 拓扑 


拓扑 信息 用 于 让 Heketi 确 认可 使 用 的 市 点 、 人 磁 副 和 和 集群， 管理 员 必 
须 目 行 确定 世 点 故障 域 和 点 集群 。 改 障 域 是 赋予 一 组 世 点 的 整数 
值 ， 这 组 节点 共享 相同 的 交换 机 、 电 源 或 其 他 任何 会 导致 它们 同时 失 
效 的 组 件 。 管 理 员 必须 确定 哪些 和 点 构成 一 个 集群 ，Heketi 使 用 这 些 信 
恩 来 确保 跨 故 障 域 中 创建 副本 ， 从 而 提供 数据 的 见 余 能 力 。Heketi 文 持 


多 个 Gluster 存 储 集群 ， 这 为 管理 员 提 供 了 创建 SSD、SAS、SATA 或 为 
用 户 提供 特定 服务 质量 的 任何 其 他 类 型 的 群集 的 选项 。 


命令 行 客户 端 heketi-cli 通 过 加 载 预定 义 的 集群 拓扑 ， 从 而 添加 区 点 
到 集群 中 ， 以 及 将 磁盘 关联 到 广 上 扣 上。 要 使 用 heketi-cli 加 载 拓 扑 文件 ， 
可 通过 以 下 命令 完成 : 


# export HEKETI_CLI_SERVER=http://<heketi server:port> 
# heketi-cli topology load --json=<topology_file> 


一 个 适用 于 当前 配置 环境 的 示例 配置 如 下 所 示 
(/etc/heketi/topology_demo.json) ， 它 将 根据 Gluster 存 储 集群 的 实际 环 
境 把 gfs01、gfs02 和 gfs03 三 个 节点 定义 在 同一 个 集群 中 ， 并 指明 各 节点 
上 可 用 于 提供 存储 空间 的 磁 一 设备 : 


"clusters": [ 
"nodes": [ 


"node": { 
"hostnames": { 
"manage": [ 
"172.16.2.36" 
], 
"storage": [ 
"172.16.2.36" 
] 


党 
"zone": 1 


"devices": [ 
"/dev/sdb", 
"/dev/sdc", 
"/dev/sdd" 

] 

}, 
{ 
"node": { 
"hostnames": { 
"manage": [ 
"172.16.2.37" 
] 


芝 
"storage": [ 
"172.16.2.37" 
] 
了 
"zone": 1 


"devices": [ 
"/dev/sdb", 


"/dev/sdc", 
"/dev/sdd" 


"node": { 
"hostnames": { 
"manage": [ 
"172.16.2.38" 
]， 
"storage": [ 
"172.16.2.38" 
] 
}, 


"zone": 1 

}, 

"devices": [ 
"/dev/sdb", 
"/dev/sdc", 
"/dev/sdd" 


而 后 运行 如 下 命令 加 载 拓 扑 信息 ， 从 而 完成 集群 配置 。 此 命令 会 
生成 一 个 集群 ， 并 为 其 添加 的 各 市 点 生成 随机 ID 号 : 


# export HEKETI_CLI_SERVER=http://gfs01.ilinux.io:8080 
# heketi-cli topology load --json=topology_demo.json 


而 后 运行 如 下 命令 查看 集群 的 状态 信息 .: 


# heketi-cli cluster info ba7657cf60195432d8cob4e3c2c94d59 
Cluster id: ba7657cf60195432d8cob4e3c2c94d59 

Nodes: 

2a73c6123e4a05ceb050bc5c433c6a07 
613754fe6267e3d7f1a731ce2e0ab94a 
8b4e57a8ce4e5640b6cc845915769f8d 

Volumes : 


“heketi-cli volume create --size=<size in Gb> [options]” 能 够 创建 存储 
卷 ， 例 如 ， 下 面 的 命令 测试 即 用 于 创建 一 个 存储 卷 : 


# heketi-cli volume create --size=20 
Name: vol _43b859b65d4ad8e0de47065b2aca7e41 
Size: 20 


Volume Id: 43b859b65d4ad8egde47065b2aca7e41 

Cluster Id: ba7657cf60195432d8cgb4e3c2c94d59 

Mount: 172.16.2.36:VvVol_43b859b65d4ad8e0de47065b2aca7e41 

Mount Options: backup-volfile-servers=172.16.2.37,172.16.2.38 
Durability Type: replicate 

Distributed+Replica: 3 


而 后 在 要 使 用 的 远程 存储 卷 的 节点 上 安装 GlusterFS 和 glusterfs-fuse 
程序 包 ， 提 供 GlusterFS 客 户 端 驱动 及 对 GlusterFS 文 件 系 统 的 运行 ， 并 
基于 GlusterFS 文 件 系统 类 型 挂 载 使 用 确认 无 误 后 即 可 删除 测试 卷 。 删 
除 Heketi 卷 的 命令 为 “heketi-di volume delete<vol id>”， 如 删除 前 面 创 
建 的 存储 卷 ， 可 使 用 以 下 命令 : 


# heketi-cli volume delete 43b859b65d4ad8eode47065b2aca7e41 
Volume 43b859b65d4ad8e0de47065b2aca7e41 deleted 


至 此 为 止 ， 一 个 文 持 动 态 存储 卷 配 置 的 GlusterFS 存 储 集群 即 设置 
完成 ， 用 户 既 可 于 Kubernetes 中 通过 PVC 请 求 使 用 某 事先 创建 完成 的 
也 可 把 Heketi 配 置 为 存储 类 ， 而 后 提供 PV 的 动态 供 
给 功能 。 


